Diseño de Un Modelo de Nomenclátor Centralizado en El Ámbito de Las Administraciones Locales de Gran Tamaño - Enrique de Dios San Román PDF

UNIVERSIDAD DE SALAMANCA
ESCUELA POLITCNICA SUPERIOR DE VILA

GRADO EN INGENIERA GEOMTICA Y TOPOGRAFA

DISEO DE UN MODELO DE NOMENCLTOR
CENTRALIZADO EN EL AMBITO DE LAS
ADMINISTRACIONES LOCALES DE GRAN TAMAO.

PROYECTO FINAL DE GRADO
VILA 2012-2013
Alumno:
Enrique de Dios San Romn

Tutor:
ngel Luis Muoz Nieto


ENRIQUE DE DIOS SAN ROMN
PROYECTO FINAL DE GRADO 2

ndice

INTRODUCCIN ............................................................................................................................................ 4
ANTECEDENTES ............................................................................................................................................ 7
ANTECEDENTES HISTRICOS .................................................................................................................... 8
NOMENCLTOR .................................................................................................................................... 8
EVOLUCIN HISTRICA DE LOS NOMENCLTORES ........................................................................... 14
EDAD MEDIA Y RENACIMIENTO ......................................................................................................... 46
ANTECEDENTES PRXIMOS .................................................................................................................... 66
SIGLOS XIX y XX ................................................................................................................................... 66
LA REVOLUCIN GEOMTICA (1980 hasta 2000)............................................................................... 84
NECESIDAD DE NOMENCLTOR ................................................................................................................. 89
TIPOLOGA DEL NOMENCLATOR MUNICIPAL ......................................................................................... 91
NOMENCLATOR INTRINSECO O PROPIO ............................................................................................ 92
NOMENCLATOR ADYACENTE O METROPOLITANO ............................................................................ 98
NOMENCLATOR EXTRINSECO O ESTATAL ......................................................................................... 105
LA NECESIDAD DE UN MODELO AUTNOMO ...................................................................................... 110
VENTAJAS E INCONVENIENTES DEL MODELO AUTNOMO ................................................................. 118
ESTADSTICAS DE USO: EL CASO DE MADRID. ...................................................................................... 121
EXPOSICIN .............................................................................................................................................. 126
CONCEPTOS Y ELEMENTOS PREVIOS .................................................................................................... 127
EL CALLEJERO Y SUS ELEMENTOS ..................................................................................................... 127
TOPONIMIA DE LA CIUDAD .............................................................................................................. 143
LOS CONCEPTOS DE VARIANTERO, DICCIONARIO Y FONO .............................................................. 158
EL CONFLICTO MULTILINGE ........................................................................................................... 176
LOS SISTEMAS DE REFERENCIA Y EL PROBLEMA DE LAS TRANSICIONES ......................................... 179
MULTIENTORNOS, PLATAFORMAS Y SU PROBLEMTICA ................................................................ 184
TECNOLOGAS DISPONIBLES. DECISIN ............................................................................................... 194
LA DECISION ACERTADA Y OTRAS TCNICAS DE DISEO ................................................................. 194
DECISIN DE BASE DE DATOS ........................................................................................................... 206
DECISIN DE LENGUAJES .................................................................................................................. 213
BASE LGICA FUNDAMENTAL DEL NOMEN-CLTOR ........................................................................... 217
CONCEPTO DE VALIDACIN ............................................................................................................. 219
CONCEPTO DE OBTENCIN .............................................................................................................. 224
CONCEPTO DE TRADUCCIN ............................................................................................................ 230


ESQUEMA DE USO Y VENTANAS ....................................................................................................... 232
DISEOS ESTRATGICOS ........................................................................................................................... 239
LA BASE DE DATOS ............................................................................................................................... 241
CONCEPTOS PREVIOS ....................................................................................................................... 242
DISEO DE LA BASE DE DATOS ......................................................................................................... 248
DISEOS ESPECFICOS ...................................................................................................................... 255
SQLSERVER. EL DISEO FSICO ......................................................................................................... 259
RELACIONES CON LA BBDD ESPACIAL .................................................................................................. 268
MODELADO INSPIRE ............................................................................................................................. 282
SERVICIOS IDEE ..................................................................................................................................... 290
SERVICIO GAZEETTER........................................................................................................................ 291
SERVICIO DE MAPAS ......................................................................................................................... 294
MANTENIMIENTO Y SINERGIAS ................................................................................................................ 315
MANTENIMIENTO ................................................................................................................................. 317
CONCEPTO TIEMPO REAL V.S. BATCH .............................................................................................. 317
MANTENIMIENTO INTERNO ............................................................................................................. 327
MANTENIMIENTO ASOCIADO........................................................................................................... 341
MANTENIMIENTO BASADO EN GEOMETRA .................................................................................... 358
SINERGIAS ............................................................................................................................................. 382
APLICACIONES CORPORATIVAS DE ESCRITORIO............................................................................... 383
APLICACIONES DE CONSULTA INDIRECTA. ....................................................................................... 391
APLICACIONES MVILES ................................................................................................................... 409
VISUALIZADOR HISTRICO DE MADRID ................................................................................................... 424
EL DESARROLLO. PUNTO DE VISTA INFORMTICO .............................................................................. 426
INTERFAZ SELECCIONADO ................................................................................................................ 426
INCORPORACIN DE SERVICIOS WEB AL DISEO ............................................................................ 429
CLASES Y MTODOS BSICOS DEL VISUALIZADOR ........................................................................... 432
OTRAS CLASES DE INTERS ASOCIADAS AL CDIGO ........................................................................ 452
DIAGRAMA DE CLASES FUNDAMENTALES ....................................................................................... 454
MANUAL. BREVE GUA DE USO ............................................................................................................ 456
BIBLIOGRAFA ........................................................................................................................................... 472



1
INTRODUCCIN

Al hablar de nomencltor de modo genrico nos estamos adentrando en un
estudio ingente de casusticas que naturalmente, es complicado aglutinar en un solo
trabajo. Pensemos en la cantidad de ciencias implicadas: topografa, filologa,
lingstica, geografa Es cierto que aunque la orientacin y naturaleza de los
nomencltores vare de uno a otro podemos establecer ciertas generalidades comunes
a todos. Este estudio pretende realizar un examen exhaustivo de los nomencltores
geogrficos pero en su motivacin tambin se halla el de poder servir de puente de
conocimiento hacia cualquier otro tipo, tratando de manera clara puntos comunes.
Para lograrlo vamos a partir de lo general hacia lo particular, de manera que
progresivamente y esa es mi intencin, casi sin darnos cuenta lleguemos a ellos.

An restringiendo el mbito de estudio a los nomencltores geogrficos, es
evidente que un estudio completo de este subtipo tampoco puede ser abordado en su
completa totalidad en un estudio de las caractersticas del que se tiene entre las
manos. Adems, como ingeniero, mi mente es eminentemente prctica y aunque me
considero algo Renacentista en el sentido de creer que el conocimiento de una
materia se interrelaciona con las dems y que es necesario tambin su conocimiento
para entender del todo aquella, me motivan enfoques prcticos y reales de los
problemas y sobre todo conseguir soluciones. El estudio generalista de los
nomencltores, e incluso particularizando a su mbito geogrfico sera un proyecto
excesivamente abstracto, lleno de tericos fundamentos, que requerira un tiempo de
investigacin que no tenemos y que adems no coadyuvara a esa visin prctica de la
que hablbamos.



Conocedores de todo lo anterior, nuestras pretensiones son mucho ms
humildes, pero tambin mucho ms directas. As que centraremos nuestro estudio en
abordar el estudio concreto de los nomencltores geogrficos municipales. Su filosofa
y prctica, proponiendo soluciones y orientaciones que sin duda constituirn gran
apoyo a quien se quiera adentrar en la especializacin de este campo de la geomtica.

Al final de este trabajo deberemos de ser capaces de tener una visin profusa
de los nomencltores geogrficos en general y un conocimiento exhaustivo de las
tcnicas necesarias para abordar con garantas un proyecto municipal de nomencltor.
Para conseguirlo, lgicamente no puede contemplarse otra cosa que no sea el estudio
del problema para un gran municipio, pues este aglutinar desde las necesarias
soluciones comunes a cualquiera con aquellas que slo se dan en grandes urbes. No
hay ninguna ciudad mayor que Madrid en Espaa (2011) ya que tiene una poblacin
del 202% respecto a la de Barcelona, que es la siguiente capital de provincia ms
poblada. Pensemos que slo si consideramos la poblacin completa de la provincia de
Barcelona, esta supera a la de la capital de Madrid. Todas las dems provincias estn
menos pobladas que la capital de Espaa y para hacernos una idea real de las
dimensiones de la ciudad de Madrid esta, est ms poblada que Comunidades
Autnomas enteras, como las de Aragn, Principado de Asturias, Illes Balears,
Canarias, Cantabria, Castilla y Len, Castilla La Mancha, Extremadura, Galicia, Murcia,
Foral de Navarra, Pas Vasco, La Rioja y por supuesto el de las ciudades autnomas de
Ceuta y Melilla. Estamos pues ante el estudio de un nomencltor de unas
caractersticas en absoluto menores que adems es demandante de empleo en un
porcentaje muy superior al de otras materias geomticas.

La mayora de las soluciones propuestas en este trabajo estn corroboradas por
la experiencia para el municipio de Madrid, en el que trabajo como Analista y otras lo
estn de los estudios especficos para l realizados. Estaremos pues hablando de
soluciones reales y contrastadas, lo cual le da a nuestra investigacin ese marcado
carcter prctico al que nos referamos en prrafos anteriores. El nomencltor
municipal ser observado desde diferentes perspectivas. Partiremos de la necesaria
visin terica, caminando sobre una conceptual que progresivamente iremos
convirtiendo en prctica.



No hemos encontrado bibliografa tcnica referida a los nomencltores
municipales y existe muy poca que verse sobre otros nomencltores geogrficos en
general. La documentacin de estudio existente prcticamente solo parte del Instituto
Geogrfico Nacional, ya que an cuando existen otras publicaciones encontradas, estas
basan su documentacin en presentar resultados de estudios sin un anlisis de
decisiones del cmo y el porqu se han abordado de un determinado modo.

Nos gustara y sera gratificante el que este estudio constituyera una
herramienta de consulta bibliogrfica, pues esto resolvera en parte la ausencia
mencionada de informacin tcnica que se observa. Pienso que los egresados en los
prximos aos tendrn una importante labor que hacer en esta especializacin
topogrfica. Nuestra ingeniera es un mundo cambiante de adaptacin continua, pero
en la idea de esta investigacin est el establecer ideas y soluciones independientes de
tecnologas concretas, de las que lgicamente y aunque haremos uso no deberan de
pasar de ser herramientas auxiliares para entender mejor el ncleo de lo que deseo
transmitir.

Por ltimo resear que no estamos ante una ciencia exacta por lo que no
podemos caer en la estulticia de pretender una solucin universal. A lo ms que
podemos aspirar es a un buen intento para la idiosincrasia concreta de las poblaciones
en Espaa. Aquellas de otros lugares, que puedan adaptarse a las caractersticas aqu
estudiadas y en cuyo modelo de informacin podamos establecer relaciones de
identificacin biunvoca numerosos, podrn probablemente adaptarse sin grandes
dificultades. Segn nos vayamos alejando entre modelos la cantidad de elementos
aprovechables de nuestro diseo se ir minimizando.

Los libros son como los amigos, no siempre es el mejor el que ms nos gusta.
(Po Baroja)



2
ANTECEDENTES

Antes de iniciar el presente estudio hemos establecido claramente en la
introduccin los lmites sobre los que vamos a centrar nuestra investigacin. Para
lograrlo, no slo ser necesario definir el concepto de nomencltor, sino conocer las
caractersticas concretas del mbito de estudio en la ciudad.

La historia como casi siempre suele ser el punto de partida para numerosos
estudios, sin cuyo conocimiento previo es prcticamente imposible tener una visin
profunda de lo contemporneo, por eso este estudio andar ese camino sin cuyo
recorrido nos hara despreciar una riqueza de conocimientos que todo especialista
debe de tener.

Iniciemos pues nuestra andadura a travs del fascinante mundo de los
nomencltores y su historia.

No saber lo que ha sucedido antes de nosotros es como ser incesantemente nios.
(Cicern S. I a.C.)
Dicen que la historia se repite, lo cierto es que sus lecciones no se aprovechan.
(Camille Se S. XIX Poltico francs)



ANTECEDENTES HISTRICOS

NOMENCLTOR

CONCEPTO

En la antigua Roma, en los banquetes, haba que distribuir a los invitados en su
correspondiente triclinium considerando entre otros factores el protocolo y tambin
los intereses polticos o personales. Un esclavo se encargaba de tan delicada tarea,
indicando a cada comensal el lectus que le corresponda entorno a la mensa antes
de iniciarse el gape propiamente dicho. As mismo, no era infrecuente que los
notables de Roma se hiciesen acompaar de un esclavo que les indicase los nombres
de personajes ilustres o que por conveniencia interesaba saludar. Cicern en el 63 a.C
habla de ellos en su obra Commentariolum petitionis y llega a desaconsejar su uso a
los candidatos a Cnsul.

El nombre que reciban estos esclavos o libertos ilustres era el de nomencltor.
El origen etimolgico del trmino proviene del latn (nomen) nombre y el verbo
arcaico (calare) llamar, por lo que podemos decir que el origen de la palabra
nomencltor es el que llama, dice o pronuncia el nombre.

En la actualidad el concepto de nomencltor ha variado, pero si nos detenemos
en la idea primaria, veremos que en su origen est el conocimiento de un conjunto de
personajes, de los que adems estos nomencltores conocan detalles como lugar de
residencia, cargos, amistades, lugares frecuentados con sus horarios y otros. Este
concepto se puede asociar sin duda al de lista de datos y conocimiento de sus
relaciones. Por otro lado el nomencltor dedicado a la distribucin de comensales
tena como misin intrnseca la de situarles en el lugar apropiado. Vemos pues que el
concepto o definicin actual est muy interrelacionado con el propio origen de la
definicin del trmino que toma.



Hoy da nomencltor es equivalente en esencia a relacin, en el sentido de lista
ordenada. Formalmente en este trabajo definiremos nomencltor en sentido genrico
como Una relacin, compilacin o glosario de nombres o datos, normalmente de
carcter tcnico y/o cientfico que sirve de recordatorio a sus usuarios.
Efectivamente, de acuerdo a esta definicin nos podemos encontrar nomencltores
farmacuticos, como el Digitalis-Integra del Ministerio de Sanidad, Servicios sociales e
Igualdad; nomencltores de nombres internacionales de marcas para los servicios de
patentes y marcas; nomencltores estadsticos para estudios concretos, e incluso
nomencltores histricos como el usado durante la Edad Media para poder
codificar/decodificar la correspondencia entre el nuncio en Espaa y el Papa, de forma
que incluso dentro de la criptografa existe un tipo histrico de encriptacin
denominada nomencltor basada, grosso modo, en la sustitucin de trminos en base
a una relacin limitada de trminos.

La Real Academia Espaola define nomencltor como catlogo de nombres, ya
de pueblos, ya de sujetos, ya de voces tcnicas de una ciencia o facultad. As el propio
diccionario podra considerarse una versin de nomencltor y de hecho en una de sus
acepciones se define a s mismo como catlogo de noticias importantes de un mismo
gnero ordenado alfabticamente. Diccionario bibliogrfico, biogrfico, geogrfico.
Aqu ya podemos ver una ligazn ms concreta entre el concepto de nomencltor y su
componente intrnsecamente geogrfica.

En el mbito de nuestra ciencia se puede definir nomencltor geogrfico como
coleccin ordenada de nombres geogrficos que se corresponde en una relacin N:N
con una posicin localizada del Universo conocido. En efecto, pensemos que un
nombre geogrfico de dicho catlogo podr corresponderse con varias localizaciones,
pero al tiempo una misma localizacin podr ser presentada con distintos nombres del
catlogo.

Es importante detenernos a comprender la cardinalidad N: N que aparece en la
definicin como nexo entre los nombres geogrficos y su posicin. Vamos a
profundizar en ello para poder comprender exactamente el porqu de la misma:



- Relacin (catlogo) 1 : N (posicin)

Antes de que el astrnomo John Flamsteed en el siglo XVIII realizase el
primer catlogo numrico de denominaciones de estrellas, era comn
bautizarlas con nombres comunes. Sabemos que en la actualidad y debido a la
gran cantidad de estrellas visibles el sistema identificativo es inequvoco y el
mismo se basa simplemente en la posicin que la estrella ocupe segn el
sistema de referencia usual en astronoma de posicin: ascensin recta y
declinacin sobre la esfera celeste. Pues bien, una de estas estrellas bautizada
segn el sistema primitivo es Sirio. Esta estrella que se perciba como una al ser
bautizada es realmente doble o dicho con ms propiedad: binaria, por lo que ya
en su propia localizacin estelar se corresponde con dos posiciones
astronmicas (las denominadas Sirio A y Sirio B), luego el nombre del catlogo
denominado Sirio tendr una correspondencia 1 : 2 con el conjunto de sus
posiciones estelares. An ms, podemos decir que Sirio tambin tiene
localizaciones no estelares, ya que tiene una correspondencia con una calle de
la ciudad de Madrid desde 1960 y tambin en Montevideo (Uruguay) y en
Zapopn (Mjico) y en otras muchas, de manera que efectivamente a un mismo
nombre Sirio puede corresponderle una o ms (N) posiciones topogrficas.

- Relacin (catlogo) N : 1 (posicin)

El nivel de abstraccin es el que ms nos ayudar a entender esta
correspondencia. Sabemos que existe una correspondencia entre una posicin
geogrfica y varios nombres geogrficos del catlogo sin ms que ir
generalizando la realidad. Imaginemos una posicin perfectamente definida en
un S.R. concreto. Pensemos que esa podra ser la posicin ms elevada del Pico
Rocigalgo (1:1). Generalizando hacia menores escalas ese punto podra
identificar el trmino municipal de Los Navalmorales (2:1) y an ms podra
identificar sucesivamente al Parque Nacional de Cabaeros (3:1), a los Montes
de Toledo (4:1) e incluso a la provincia de Toledo (5:1). Evidentemente la
visualizacin que de ese punto (centroide de una extensin que va de 0 a
infinito) pueda dar un mapa, depender de la escala de visualizacin del


fenmeno o de la orientacin temtica del mismo, sin embargo ese punto
puede tener todos esos nombres geogrficos asociados.

Vamos a usar otro ejemplo para entender esta cardinalidad N:1, al
tiempo que introducimos el factor temporal en los nomencltores.
Imaginmonos una posicin de una determinada poblacin. Adems de poder
tener relacin con el catlogo de denominacin de la propia ciudad, con su
delimitacin municipal y censal, puede tener una variabilidad nominal afectada
por variables temporales. En Madrid, por ejemplo, en 1967 la posicin
geogrfica denominada C/ Joaqun Garca Morato n 77 hoy es C/ Santa
Engracia n 73 y representan exactamente la misma posicin.

Visto lo anterior y la importancia de la variable temporal a la hora de
confeccionar ciertos nomencltores, definiremos como nomencltor geogrfico
histrico: coleccin ordenada de nombres geogrficos que se corresponde en una
relacin de N:N con una posicin localizada del Universo conocido en un momento
dado.

Un nomencltor municipal deber de corresponderse con la definicin dada
para un nomencltor geogrfico histrico. Un nomencltor poblacional que slo tenga
en cuenta el momento actual podr ser vlido pero desde nuestro punto de vista se
corresponder a un caso particular de nomencltor poblacional histrico, que ser el
caso ms completo a proyectar.

Por ltimo diremos que una posicin localizada del Universo, aunque estemos
actualmente acostumbrados a identificarla por coordenadas (sobre todo a partir de
que el Gobierno de EEUU autorizase el uso del sistema GPS para usos civiles) no tiene
porque ser georrefenciada matemticamente sobre el elipsoide, sino que puede ser
reconocida de forma descriptiva. De hecho esta es la forma natural en la que el
hombre tiende a describir cualquier identificacin al ser el modo ms universal y
simple de hacerlo. Cuando alguien pregunta en dnde vives?, no respondemos
diciendo latitud X, longitud Y en el sistema de referencia K, sino simplemente lo
hacemos considerando el contexto y respondiendo en funcin de l. Simplemente


responderemos nombrando el continente, el pas, la poblacin, el barrio o en ltima
instancia la calle y nmero del lugar u obviaremos varios de ellos dentro de ese
concepto de relacin N:1 al que nos hemos referido anteriormente.

OTRAS DEFINICIONES Y ESTADO DE COSAS

Un concepto como el nomencltor puede definirse de muchas maneras. Arriba
hemos dado nuestra definicin personal, creyndola acertada, sin embargo debemos
de considerar otras definiciones que nos parecen especialmente interesantes, como la
de Carmen Muoz Cruzado de la Universidad Politcnica de Madrid al referirse a
nomencltor como: Catlogo de entes del mundo real que contiene alguna
informacin sobre su posicin. Especialmente me gusta esta definicin por su sencillez,
y teniendo en cuenta que se est refiriendo directamente al concepto de nomencltor
geogrfico. Esta definicin est muy institucionalizada y reconocida porque es la que
se da en ISO 19112. Tambin la hemos vista recogida por Alejandra Snchez Maganto.

El Instituto Geogrfico Nacional de Espaa define nomencltor como un
catlogo ordenado de topnimos con informacin sobre su ubicacin, el tipo de
entidad geogrfica y cualquier otra informacin descriptiva o definidora de cada
topnimo. La importante misin del I.G.N. en la generacin de nomencltores est
fuera de toda discusin. Ya en su da, las Naciones Unidas aconsejaban la realizacin de
nomencltores nacionales que normalizasen la informacin en cada pas. En este
sentido y con referencia al nomencltor geogrfico conciso de Espaa es importante
decir de cara al enfoque de nuestra investigacin que en Madrid y con referencia a la
revisin toponmica se ha contado con la Direccin General de Cooperacin con la
Administracin Local de la Comunidad de Madrid, de manera, que el producto es una
toponimia doblemente revisada. Lo lgico es que terminado el proyecto (an no lo
est a diciembre 2012), ste sirva de base para establecer el nomencltor geogrfico
de Espaa, de manera que sin limitaciones restrictivas (en el conciso, la escala de
partida para toponimia es muy pequea y eliminaciones como la de poblaciones de
menos de 2000 habitantes hacen que est muy enfocada a la ejecucin de cartografa
a gran escala ms que a la interoperabilidad del mismo) quizs pueda llegar a ser
usado como centralizado por todas las Administraciones.



Es evidente que algunos topnimos han podido nacer de condicionantes o
ideologas, aunque la mayora lo hace por motivos mucho ms naturales. Tambin es
cierto que una determinada lengua o dialecto (hablaremos de ello ms adelante)
puede ser origen e incluso destino histrico de un topnimo (por derivacin del
original o en su propio germen). El topnimo, aunque mucho menos que otros
nombres geogrficos (pensemos en el callejero de una ciudad y sus avatares)
sobrevienen o nacen como elementos del lenguaje que son, pero tambin evolucionan
de acuerdo a las reglas del mismo, no estando exento de perturbaciones. Bajo mi
punto de vista la toponimia tiene que ser tratada como lo que es, es decir, un
elemento de los identificadores geogrficos que debe de ser anotada y estudiada por
profesionales. Mi visin personal es que la poltica est trastornando ese orden de
desarrollo natural para, olvidndose de toda la riqueza que se aporta en ese camino,
desnaturalizarlo por Decreto, despreciando as la evolucin del hombre mismo. Vemos
ejemplos:

- La localidad de Sanxenxo es un nico topnimo por decreto debido a la Ley
3/1983 de normalizacin lingstica que en su artculo 1 dice que los
topnimos tendrn como nica lengua oficial la gallega. Esto ya en pura
concepcin es un disparate. Un topnimo en Galicia, por lo general derivar al
gallego, pero esto no es una regla exacta. As pues, tengo claro que Sanxenxo
es un endnimo de dicha poblacin, pero no podemos descartar la idea de que
Sangenjo o Sanjenjo son exnimos. Todos ellos pues topnimos espaoles de
una misma localidad desarrollo del original Sanctus Genesius
- La localidad de Fisterra tambin ha sufrido las consecuencias de una ley
basada en principios proteccionistas de la lengua gallega en vez de en
criterios tcnicos. La Finis Terrae (el fin de la tierra) ya conocida en la antigua
Roma aparece en mapas del S. XVI en adelante como Finisterre. Parece en este
caso que la galleguizacin del trmino no es clara. Aparecen ambos trminos
Finis Terra, Finibus Terra, fiinsterra (S. XIII XIV). En toda la cartografa siempre
aparece el endnimo Finisterre (al menos desde el S XVI). En todo caso Fisterra
es la derivacin de Fi-n-is Terra al perder el gallego la n- intervoclica y creo
que debera de convivir como endnimo con Finisterre. La poltica en este caso
elimina probablemente un endnimo propio.
- En Catalua la toponimia tambin es responsabilidad de la Comunidad
Autnoma, de manera que en este caso el territorio dispone de Instituto
Cartogrfico propio que es el encargado de la revisin toponmica.


(http://www.icc.cat/esl/Home-ICC/Mapas-fotos-aereas/Toponimia-nombres-
de-lugar). Creemos que se ha realizado un trabajo muy profesionalizado y ello
se deja notar, sin embargo tambin es clara la intromisin poltica en algunos
supuestos. Personalmente y en cuanto a los nombres provinciales creo que
siempre hubiese sido mucho ms acertado el modelo Valenciano de dualidad
(Alacant/Alicante). Por qu no pueden convivir los topnimos Sant Boi de
Llobregat y San Baudilio de Llobregat?, Por qu no Girona y Gerona?. En este
ltimo caso, la ciudad proviene de la localidad romana de Gerunda y en mi
opinin debera de haberse conservado el nombre Gerona como endnimo del
lugar junto a Girona (Gerunda(latn) >Girona(Cataln) > Gerona(Castellano)).

La toponimia es una riqueza en s misma y desvela nuestra etnologa y por ello
es til a otras ciencias como la lingstica, la geografa y la historia. Sin duda, los
topgrafos debemos ser fieles a un anlisis toponmico basado exclusivamente en el
rigor cientfico, logrando que nuestros nomencltores dejen una herencia fidedigna de
lo existente.

EVOLUCIN HISTRICA DE LOS NOMENCLTORES

PREHISTORIA

Bote pronto, resulta chocante el hecho de remontarnos a la prehistoria para
hablar de un nomencltor. Pretendo visualizar la intrnseca relacin entre el hombre y
su necesidad por enumerar lugares como medio de comunicacin humano y seguir las
pistas que las distintas civilizaciones nos han dejado al respecto. Es evidente que al
hablar de la prehistoria, entramos en un terreno en el que la certidumbre muchas
veces es imposible. La realidad de lo conocido no obstante, nos puede llevar a
aventurar hiptesis posibles.

Desde tiempos prehistricos el hombre ha tenido la necesidad de orientarse.
Aquellas tribus del Paleoltico en sus continuos movimientos de trashumancia en busca
de caza y alimentos ya deberan de referir primitivos topnimos (bien con sonidos
guturales que mentalmente eran interpretados, bien mediante gestos y/o


movimientos) para dar cuenta de posiciones concretas. Pensemos en aquellos
habitantes de la cueva de Altamira hace 35.000 aos pintando aquellos animales. No
es costoso pensar que entre ellos refirieran el lugar en donde tal o cual bisonte o
ciervo haban sido abatidos o en dnde podan encontrarse las mejores maderas o
piedras para realizar sus primitivas herramientas. Es probable que an antes los
topnimos apareciesen. Es viable que al menos hace 500.000 aos, pues el hecho de
que en tiempos del Homo Heidelbergensis, antecesor del Neandertal, hubiese
enterramientos de dinmica simblico-funeraria de ms de treinta individuos, tal y
como se ha demostrado en la Sima de los Huesos en Atapuerca, nos hace pensar que
es factible. Nos revela que ese lugar tena que poder ser identificado de alguna
manera, puesto que fue recurrentemente visitado por una poblacin mvil.

Idealizacin de la poblacin de los Millares en Antequera (Mlaga) hace 5000 aos (Fte: Jos Torres)

Sin embargo las primeras direcciones de la Pennsula, creemos que se
remontan a la llegada del Neoltico ibrico (desde 8000 hasta 5500 aos), en el que las
poblaciones trashumantes finalmente se asentaron dando lugar a la ganadera
propiamente dicha y a la agricultura. Sin duda aquellos hombres se referiran a lugares
dentro de sus poblaciones y se identificara la situacin de un miembro o una familia
de alguna manera que nos es imposible conocer, pero que sin duda se producira.
Seran identificaciones bsicas como la cabaa de<referencia a algn elemento,
pintura>, en dnde est<algo cercano a la misma>. Si desde hace 500.000 aos
hasta el Paleoltico inclusive es factible que aparecieran y se utilizaran los primeros


topnimos de la humanidad, tambin lo es que en el neoltico lo hicieran las primeras
direcciones de la historia.

Debemos tener en cuenta que hace 8000 aos aparece en una pared de Catal
Hyk en Turqua, lo que se puede considerar como el primer mapa conocido del
mundo. Fue descubierto en 1963 y en ella aparece la aldea de Catal Hyk y al fondo
los dos picos gemelos de Hasan Dagi.

Pared de Catal Hyk (Pintada hace 8.000 aos)



Lenguas habladas en la pennsula al final de la Edad de Hierro -Fuente Alcides Pinto basado en el mapa
del arquelogo portugus Luis Fraga

La Edad de los Metales, conformada cronolgicamente por las de Cobre,
Bronce y Hierro comienza en nuestra Pennsula hace unos 5500-5200 aos. Para el
objeto de nuestro estudio es bsico que sea en este periodo prehistrico en el que el
lenguaje escrito hace aparicin. La Edad de Hierro, ltimo periodo de la edad de los
metales y final de la prehistoria, se extiende en la pennsula durante algo ms de cinco
siglos (desde hace 2800 a 2220 aos), momento en el que Roma hace su aparicin.


Arriba columna de un Talayot de Hospitalet Vell en Menorca- Abajo defensa amurallada de talayot y
taula en primer trmino del poblado de Trepuco en Menorca.

Es tambin importante de cara a nuestro estudio el saber que en este periodo
tiene lugar el nacimiento de las poblaciones tal y como hoy las concebimos. Ejemplos
claros los tenemos en las Baleares en donde el rastro de la cultura talaytica (torres


defensivas y amurallamiento entorno a las poblaciones) con sus famosas taulas
(monumentos de culto en forma de T simbolizando al toro) constituyen memoria viva
de aquella poca.

De hecho, de este tiempo de la Edad de los metales nace la segunda referencia
cartogrfica conocida y nuevamente tambin como en el de Catal Hyk se trata de un
plano de una poblacin (4500 aos). Efectivamente representa la ciudad de Ga-sur en
Babilonia (Irak) sobre una tabla de 7 cm de longitud. Por su parte y como ms cercana
a la Pennsula tenemos la representacin De Valmnica en una roca de 50 metros
cuadrados con tallados geomtricos de animales y personas que podran representar
las poblaciones cercanas, as como accidentes orogrficos e hidrogrficos del terreno y
que fue descubierto en el ao 2005. Pensemos que curiosamente las dos primeras
referencias cartogrficas de la historia se refieren a planos de ciudades.

Valmnica (Italia) Hace 3000 aos



Arcilla de Ga-sur representando dicha ciudad Babilnica.

Pero durante este periodo y en concreto en la Edad de Hierro va a tener lugar
un hecho absolutamente esencial para poder llegar hasta nuestro nomencltor y es ni
ms ni menos que el nacimiento de nuestra escritura madre: El alfabeto fenicio. El
alfabeto fenicio proviene del protocananeo, del cual han sido encontrados textos en
Levante durante la Edad de bronce. Tenemos incluso constatacin de las equivalencias
o derivaciones desde el protocananeo al fenicio (tambin llamado pnico en su
variante derivada occidental [Cartago]) como los que podemos ver en la siguiente
tabla:

Protocananeo Fenicio



Inscripcin pnica encontrada en Tunez (Autor : Habib Mhenni)

Los fenicios, procedentes del actual Lbano/Siria fundaron la primera ciudad en
la pennsula y la denominaron Gadir (Cdiz) hace 2.800 aos. Tambin fundaron
Malaka (Mlaga), Sexi (Almuecar) o Abdera (Adra), comerciando principalmente con
los Tartessos (Turdetani en latn) e introduciendo en nuestra tierra el olivo, la vid y
nuevas tcnicas de fundicin y salazn para mejorar el mantenimiento de los
alimentos. Los fenicios fueron los grandes marinos de su poca con tcnicas
constructivas novedosas que les permitieron navegaciones de altura con las que
comercialmente no pudo competir ni el gran Imperio Egipcio. Prcticamente sus
Gaulos (nombre dado por los griegos que significa baera) comerciaron por todo el
Mediterrneo. Sin duda saban guiarse durante el da a partir de los accidentes
orogrficos de la costa, pero sera comn fondear al ocaso, (En muchas ocasiones as
iban naciendo los distintos puertos y colonias fenicias de la costa), aunque tambin
ms raramente, podan aventurarse a la noche guindose por la Osa Mayor (entonces
llamada estrella fenicia). Las tcnicas de navegacin fenicias eran realmente
ingeniosas: nforas para iluminar el camino en la noche, un sistema de palomas


mensajeras para navegar en niebla y tablas de distancia, llegando a ser los primeros en
circunvalar el continente africano por encargo del Faran Saita Necao hace 2600 aos
segn Herodoto nos relata.

Sin duda en este periodo final de la prehistoria (Edad de Hierro) y con el grado
de especializacin que consiguieron los fenicios en navegacin, podemos aventurar
que naceran los primeros documentos, esquemas y croquis topogrficos de la costa
con el fin de transmitir el conocimiento entre su pueblo. Por otro lado la fundacin de
colonias y el conocimiento del nombre de las existentes con las que se comerciaba
hacan que esos accidentes orogrficos se relacionasen con las poblaciones y formaran
parte de ellos. Se tratara de las primeras cartas marinas, no obstante es probable que
dicha informacin se hiciese en materiales relativamente delebles con el fin de no
poder ser conocidos por el resto de civilizaciones, lo que hubiese hecho peligrar su
hegemona. Desconocemos la existencia de ellos (los primeros portulanos), pero se
trata nuevamente ms que de una hiptesis, de un hecho cierto.

Parece razonable que acompaando a dichas cartas y conocida la escritura, se
diera tambin la primera coleccin de la relacin de lugares existentes dentro de una
poblacin para fines organizativos de sus habitantes y/o comerciales, tendran
relaciones ordenadas de los puertos y ensenadas y tambin habra listas con la carga y
su posicin en la embarcacin para optimizar la logstica de carga/descarga (ingeniera
del transporte). Todo ello prximo al concepto de nomencltor.

Concluiremos resumiendo, que en este periodo prehistrico el hombre dispona
de direcciones tribales desde el Neoltico, haba plasmado en mapas sus ciudades y
ahora se dispona del lenguaje escrito y un grado de tecnologa superior que adems
por la expansin fenicia estara extendindose por la Pennsula. En estas condiciones,
no es extravagante pensar que se desarrollasen los primeros nomencltores
geogrficos (El propio mapa de Ga-Sur nos presenta una combinacin de informacin
literal y grfica). Tambin es razonable que apareciesen los primeros croquis de rutas
martimo-terrestres (Cmo voy de aqu a all?).



Estamos en la prehistoria y ya es evidente la total interrelacin entre
nomencltor y mapa. Creemos que los primeros nomencltores de la Pennsula seran
probablemente escritos en alguna de las seis lenguas que coexistan en nuestra
pennsula o en el idioma de los recin llegados fenicios.

Idealizacin de placa de plomo encontrada en Gador con escritura Tartsica en la que se aprecia una
relacin sobre papel rayado y tres registros de entrada seguido de nmeros (la escritura Tartesa va de
derecha a izquierda), lo que podra representar una relacin de materiales elementos y su cantidad, lo
que encarnara una relacin de elementos y nmeros.(Descubierta en 1862)

Seremos no obstante prudentes y aunque, quin no imagina no descubre, lo
cierto es que no se ha encontrado un verdadero nomencltor, ni cartografa en la
ltima poca prehistrica en la Pennsula. Insistimos en la creencia de que debi ser en
este periodo cuando nacieron los precedentes que daran lugar a los nomencltores
actuales y que ellos debieron ser escritos en Tartesso o en fenicio, los dos pueblos ms
florecientes que en aqul momento la habitaban.



HISTORIA ANTIGUA

El alfabeto fenicio dio lugar al arameo (lengua predominante para los Asirios [Irak]) y al
griego y se cree que de este ltimo una vez introducidas las vocales naci, entre otros,
el latn. Veamos las correspondencias y observemos como una misma letra del
alfabeto fenicio da lugar a los distintos sonidos de las vocales.

Alfabeto fenicio Alf. latino Alf. griego

alp buey A, E, I, O, U , , , , , , ,

bt casa B, F ,

gaml camello G

delt puerta D

he ventana H, ,

wau anzuelo U

zai arma SD, SS, S; Z

,

et muro H,

,

tet rueda T


yod mano I

kap
palma (de la
mano)
CH, H

lamd aguijada L

mem agua M

nun serpiente N

semk pez S

ain ojo

pe boca P, PH, F ,

ade caza ST, TS, TZ; T; S

,

qop mono K

ro cabeza R

in diente S

tau seal TH



Sin duda, en nuestra cultura los pueblos ms influyentes han sido los griegos y
por supuesto, tambin los romanos. Nuestro territorio fue parte importantsima y
hasta mimada de aquel Imperio. Roma adems, absorbi gran parte de la cultura
griega. Se hace pues necesario adentrarnos en sus ciudades para ir siguiendo el rastro
de la evolucin de nuestro objetivo: las ciudades, sus planos y sus nomencltores.

GRECIA

El origen de las grandes ciudades griegas como Atenas o Esparta surge de
iniciativas personales para que un conjunto de aldeas conformaran una unidad poltica
cuyo centro fueran las denominadas ciudades-estado o polis.

En el caso de Atenas, que ser el modelo inicial para nuestro estudio, fue el rey
Teseo el que inici esta reorganizacin en la regin del tica. Atenas se fue
conformando en torno a la Acrpolis en un enjambre de casas humildes distribuidas
desordenadamente entre calles estrechas y serpenteantes.

Antes de conocer mejor algunas ciudades griegas es importante destacar
algunos aspectos importantes de cara a nuestro estudio.

Se dice que Atenas tiene una historia aproximada de 5000 aos, pero su poca
dorada se produce hace 2500 aos con la era Pericles que fue un verdadero impulsor
de las artes y la tecnologa. Gracias a la liga de Delos mantuvo a raya al Imperio persa
que ya haba asolado Atenas una vez, siendo bajo su mandato construido el famoso
Partenn. Herodoto, amigo de Pericles, realiza descripciones de lo visto (HISTORIA) a
modo de viajes por el mundo. Veamos un ejemplo del libro IV de su obra LA
HISTORIA:

A una distancia de otros diez das de camino de los garamantes hay
otra loma de sal, as como agua. El lugar, en este caso, se halla
habitado por unos sujetos cuyo nombre es atarantes. Estos individuos


son, que nosotros sepamos, los nicos hombres del mundo que
carecen de nombres propios, pues, aunque, en conjunto, reciben el
nombre de atarantes, cada uno de ellos, individualmente, no posee
nombre alguno.

Ms all, a otros diez das (de camino), hay otra loma de sal, as
como agua; se trata de un lugar que se halla igualmente habitado. En
las cercanas de esa masa de sal hay una montaa cuyo nombre es
Atlas.

Y en dicha zona, a intervalos de diez das de camino, hay un
yacimiento de sal y gentes que lo habitan. Por cierto que, como en
esas regiones de Libia ya no llueve, las casas de todas esas gentes
estn construidas con bloques de sal, dado que, si lloviera, las
paredes, al ser de sal, no podan tenerse en pie

Aproximadamente hace 2400 aos tenemos que destacar al discpulo de Platn
llamado Aristteles, que adems fue maestro de Alejandro Magno, hijo de Filipo.
Aristteles es el primer defensor con argumentos de peso del concepto de tierra
esfrica. Es cierto que otros antes haban esbozado ideas cartogrficas interesantes
(Thales, Anaximandro [autor del primer mapamundi de la historia], Hecateo e incluso
Platn), pero es Aristteles quien hace ver en su Metafsica que segn sea la posicin
del observador las estrellas parecen modificar su altura sobre el horizonte y se fij en
el hecho de que en los eclipses lunares la lnea del cono de sombra era redonda. Es
cierto que un siglo antes Parmenides en la poca de Pericles se haba referido a la
tierra como esfrica, pero lo haba hecho pensando en la perfeccin artstica que para
los griegos representaba esa figura y no haba en su defensa ninguna demostracin.

Hace unos 2300 aos Didearco se puede considerar el primer topgrafo al
dominar la geografa, medir las principales montaas de Grecia y escribir Viaje por el
mundo al que acompaa un mapamundi de un autor que defenda la esfericidad de la
tierra (primera proyeccin de la historia).


Mapamundi de Didearco (2300 aos).
Observense las dos lneas precusoras del meridiano 0 (meridiano de Rodas) y del ecuador.

Por ltimo en este viaje que estamos realizando por los avances cartogrficos
de Grecia hay que destacar hace 2250 aos la presencia del responsable de la
biblioteca de Alejandra que midi por primera vez y con una desviacin impresionante
para los medios de la poca la longitud del meridiano esfrico. Por ltimo destacar que
gracias a las informaciones de los topgrafos de Alejandro Magno pudo realizar
tambin el mapamundi ms completo de la poca. Adems Eratstenes integr la red
de meridianos y paralelos por primera vez en un mapa.

Mapamundi de Eratstenes basado en las informaciones de los topgrafos de Alejandro Magno


Por ltimo comentar que no todo fueron aciertos en el avance de la topografa
en Grecia ya que en el 2100 Posidonio de Rodas, discpulo de Eratstenes volvi a
medir el meridiano equivocndose por mucho con respecto a la correcta cifra dada por
su maestro. Sin embargo dicha medicin fue considerada como buena durante quince
siglos.

El ltimo gran hito de la cartografa griega fue la invencin del primer globo
terrqueo de la historia. Creado por Crates de Mallus hace unos 2100 aos en el que
sin conocimiento y por puro sentido del equilibrio situ territorios que se
corresponderan con Amrica del Sur y del Norte y Australia. El trmino antpodas
por l usado se generaliz en el lenguaje.

Recreacin del globo de Crates (wikipedia) y basada en un original de Edward Luther Stevenson.

Hecho este repaso que nos sirve para conocer los grandes avances
cartogrficos que se produjeron mientras la ciudad creca, volvamos nuestros ojos a
ella y estudiemos cmo evolucionaba Atenas.


A primera vista el aspecto que daba la ciudad se divida bsicamente en tres
partes principales: Acrpolis, gora y viviendas. La Acrpolis era magnfica y en ella se
albergaban los edificios religiosos. Esa imagen cuidadsima de esta zona de la ciudad
contrastaba con los barrios agrupados por oficios en los que las calles no estaban
pavimentadas y en cuyo camino era raro ver sobresalir casas acomodadas incluso en el
mayor esplendor de Atenas (la ciudad viva sus calles y plazas ms que sus viviendas,
salvo cuando llegaba la noche en la que la ciudad se converta en peligrosa.) El tercer
elemento de la ciudad era el gora del Cermico con los edificios pblicos ms
importantes, varios prticos (stoas) y centro de talleres y mercaderes, abarcando una
zona amplsima.

Como dice Jos Muoz Jimnez en su libro La ciudad en la antigua Grecia,
este tipo de ciudades avanzadas se diferencian de las previas en diferenciar zonas de
culto, de produccin, comercial, administrativa y defensiva y aspectos como la calzada
central, el diseo arquitectnico de los edificios segn su cometido y la jerarquizacin
zonal son descriptivas de Atenas, pero tambin es cierto que dicha evolucin y
estratificacin zonal dentro del concepto de ciudad ya se encuentra en pocas
anteriores en Mesopotamia y Egipto

Principales elementos de Atenas clsica. Fuent : Blog de Antonio Boix.


Un aspecto urbanstico destacable y curioso es el resultado de garantizar a toda
costa la lejana del puerto (miedo a las invasiones piratas al establecimiento de la
ciudad) y al tiempo lograr una ptima conexin segura con el mismo (en realidad tres,
pero principal el del Preo y ms antiguo el de Falern) para lo cual se construyeron
con el fin de garantizar el abastecimiento dos magnficas murallas de 6 Km, entre las
cuales haba una calzada de 160 metros de ancho.

Atenas hace 2500 aos Fuente web AlgargosArte

Vista deAtenas, sus tres puertos y su conexin con la ciudad (Fuente web AlgargosArte)



Destacados algunos elementos de la ciudad seguiremos incidiendo en aspectos
urbansticos que van configurando elementos toponmicos:

Unos topnimos sern descriptivos de su entorno orogrfico como el montculo
de Arepago (pago es monte en griego antiguo. -Monte de Ares- y en l se juzgaban
los delitos de sangre) o la Acrpolis (Acro en griego significa elevado. la parte elevada
de la ciudad), de su fauna, como la colina de Licabeto (la colina de los lobos) o de su
utilidad, como la caada del Pnix (en donde los oradores se dirigan al pblico.) y el
gora del Cermico o tambin de su historia o leyenda como en el caso del Kerameicos
(cementerio de la ciudad que en sus orgenes haba sido un suburbio habitado por un
hroe ceramista).

Otros corresponderan a topnimos nominales, populares u oficiales como el
teatro de Dionisio cerca del oden (competiciones de canto) de Pericles, el estadio
panatenaico o la muralla de Temistocles, as como los nombres de los distintos
prticos (stoas media y meridional en esta poca) en donde se realizaban actividades
diversas y se encontraban dispersos por la ciudad. Adems tendramos otros
elementos ralos como el monumento de Filopapo junto a la muralla en su zona sur o la
torre de los vientos.

Habra topnimos relativos a la proximidad del rio Ilisos (junto a la ciudad) y el
ms lejano Cefiso, usado este ltimo para el riego principalmente, con prticos (como
el de Meliticles o Dipilo) que daban a puentes que lo cruzaban y que tendran nombres
propios. As mismo los manantiales, pozos, aljibes y fuentes ms importantes seran
conocidos con nombre propio (Fuente de Calrroe la de bello chorro y Fuente de
Eneacrunos de los nueve caos nombrada por Herdoto).

Atenas sera pues una lgica evolucin de las aglomeraciones urbanas de la
ltima parte de la Edad de Hierro en la que se dio adems un deseo por ser la gran
ciudad del mundo conocido. El propio concepto de ciudad-estado hace ver lo
primordial que era poner el mayor empeo urbanstico en cuanto a su
monumentalidad. Sin embargo Atenas tena un gran problema: El crecimiento rpido y
continuo de una enorme aglomeracin urbana.


Efectivamente Atenas lleg a tener 200.000-300.000 habitantes (pensemos en
ciudades como Corua, Granada o Vitoria en la actualidad). Tras la destruccin de
Atenas por los Persas, Pericles se afan en una reconstruccin ms estructurada
(nacimiento del Urbanismo), de manera que en la ciudad de Atenas existen dos
modelos urbansticos diferenciados (antes y despus de Pericles). A Pericles se le debe
el inicio de la construccin de los muros de defensa para unir Atenas con el puerto y la
creacin de algunas barriadas (personas pudientes) con calles ms anchas trazadas a
cordel y con rboles de sombra en sus calles, construy los Propileos como acceso a la
Acrpolis.

El rio Cefiso en Atenas en la actualidad bajo una autopista (fotografa: Ggia)

Desde el punto de vista de nuestro estudio, resulta relevante que en Atenas
podamos ver no slo que las vas de salida de la ciudad reciban distintos nombres con
su correspondiente puerta de entrada a la ciudad (componente hacia<lugar>) como
eran la va a la Academia, a Maratn, etc. sino que alguna de ellas prolongan su
trazado dentro de la ciudad, de manera que estas calles resultaban tanto por su
anchura como por su linealidad (caminos previos) puntos de referencia para recorrer la
ciudad a modo de grandes avenidas. Tal era su importancia que recibieron nombre


propio como la va procedente del templo de Eleusis que era la llamada va Sagrada
que accediendo a la ciudad a travs de la puerta del Dypilon se converta en la calle de
Panateneas y que divida la ciudad en dos partes cruzando el gora. Otras han sido
documentadas como la calle de los Trpodes (llamada as porque a los ganadores de
premios teatrales como el de las Dionisiacas, se les daba un trpode que ellos
colocaban en dicha calle (El trpode tena un gran simbolismo para los griegos).

Es fcil abstraerse y pensar que en estas condiciones, con una ciudad
complicada de recorrer, los habitantes sintiesen una gran necesidad de orientarse. La
ciudad como hemos visto les dio los elementos bsicos para poder hacerlo:

- Una gran arteria central
- Varias rutas de salida de la ciudad con sus prticos.
- Grandes elementos superficiales destacados
- Calles con nombre (Nacimiento del concepto calle de un callejero actual)
- Elementos dispersos destacados (fuentes, monumentos)
- Barriadas por nombres.

Vemos con ello que de repente nos hemos acercado muchsimo al concepto
posicional de la ciudad actual, es decir, a la manera en la que nos orientamos por ella e
indicamos a otros una ruta concreta para llegar de un lugar a otro, lo cual puede ser
comprobado en el libro I del tica y Megara de Pausanias cuando dice:

De Pritaneo (Ayuntamiento) baja una calle llamada trpodes, notoriamente conocida

Es ms que posible que aqu surgiese el primer concepto de callejero y que la
propia ciudad para poder funcionar tuviese que utilizar los primeros nomencltores
debido a las necesidades que generaran los servicios: pequeo cuerpo de basureros,
polica e inspectores que velaban por el cumplimiento de las primeras normas
urbansticas de la historia.


Aristteles dice en su Constitucin de Atenas:

Adems se eligen por la suerte comisarios de' los
santuarios, en nmero de diez, que reciben treinta
minas de los receptores y disponen lo ms necesario
para los santuarios; y diez astnomos, de los que
cinco mandan en el Pireo y cinco en la ciudad, los
cuales inspeccionan a las flautistas, msicas de lira y
citaristas para que no cobren ms de dos dracmas
de salario, y si varios desean disponer de la misma,
ellos la echan a suertes y la ponen a sueldo de aquel
a quien corresponda. Y cuidan de que los basureros
no descarguen la basura a menos de diez estadios
de la muralla, y han de impedir que se edifique en la
calle y que se tiendan balcones por encima de las
calles, y caeras que descarguen en la calle desde lo
alto, y ventanas que abran a la calle; y recogen a los
que mueren en la calle, pues disponen de los siervos
pblicos.

Urbansticamente se produce el primer ejemplo de planificacin de la ciudad,
es decir, el primer plan de ordenacin urbanstica y el nacimiento con ella de la
ciudad ortogonal. Segn F. Castagnoly el nacimiento se produce en paralelo en Grecia
y en las colonias griegas de Roma (estos tomaran este conocimiento probablemente
de las ciudades griegas de Italia), aunque ya hace 3900 aos en Egipto, en la ciudad de
El Lahoun se pueden apreciar ciudades que apuntan a geometras de ngulo recto.



Plano de la villa y pirmide del Faran Sesostris II segn el egiptlogo Flinders Petrie (1890)

La personificacin de este hito urbanstico se centra en la figura de Hipdamo
en la poca de Pericles y que se haba formado en la reconstruccin de Mileto. As se
inicia la nueva era de la edilicia (obra de carcter municipal) griega que se arrastra
hasta nuestros das y que resumidamente se basa en un modelo ortogonal, gora
central, teatro en periferia, dotacin de alcantarillado, tendencia llana, o en su defecto
en terrazas y en el que las vas principales son dobles que las convencionales.

Diseo de Hipodamo del puerto de Pireo y comparacin con el PAU de Sanchinarro de Madrid
(Dos mil quinientos aos los separan)


Similitud entre el Agora de Atenas y la Plaza de Cibeles en el S XIX en Madrid
Apuntes de arquitectura n 20 | Cuadro de Jose Mara Avrial

El diseo de damero favorece la numeracin de las calles como sentido de
orientacin (tal y como ocurre en Manhattan), pero en este sentido no tenemos dato,
ni indicio fehaciente de que pudiese haber algn avance en este sentido en la Atenas
clsica.
Destacar por ltimo que el trmino topografa se origina en la Grecia antigua y
proviene de las palabras topos (lugar) y graphia (escribir) y sabemos que Alejandro
Magno antes de que Roma desbancase a Grecia en sus expediciones tena buen
cuidado de llevar a unos cuantos de nuestros antecesores de profesin, adems de
escritores.

ROMA

Si en Grecia nace la topografa en Roma nace el topgrafo urbanista y de obras
y lo hace fundamentalmente por la necesidad que tiene Roma de realizar grandes
infraestructuras para el correcto funcionamiento del Imperio. Es obligado disponer de
especialistas en geometra que supieran aplicarla prcticamente. Desde la parcelacin
de tierras hasta el alcantarillado y la captacin de agua pasando por la construccin de
campamentos y sin olvidar su misin de gegrafos hizo el resto para que naciese de


facto nuestra ingeniera y que fue fundamental y decisiva para el desarrollo social y
militar de Roma.
La instrumentacin de un agrimensor romano se basaba en cuerda, cadena,
decempeda, odmetro, jalones, groma, escuadra, gnomon, libra acuaria, corobate,
dipotra y lmpara y deba conocer y aplicar las teoras de Tales, Pitgoras, Euclides,
Apolonio, Arqumedes e Hiparco.
Vitrubio en el siglo I a.C. habla sobre estos instrumentos y su correcto manejo
en su libro X de arquitectura:

Texto de Vitrubio y Groma fabricada por Matthias Kabel

Por otro lado y aunque los servicios de transmisin de mensajes escritos seran
tan antiguos como la propia escritura realmente es en los tiempos de Augusto, sucesor
de Julio Cesar y nacido en el 63 a.C. cuando se instaura el primer servicio postal regular
del mundo, lo cual fue posible gracias a la impresionante red de comunicaciones del
Imperio. El servicio se llamaba Cursus publicus. Haba un servicio rpido tirado por
caballos y otro ms lento tirado por bueyes. Ambos en un principio estaban reservados
al gobierno, pero posteriormente se aadi un servicio ms para los ciudadanos. El
trmino postal hace referencia a las postas (posata) en donde descansaban aquellos
primitivos carteros. En los actuales nomencltores poblacionales, el cdigo postal es


un elemento importante que cobra una importancia trascendental en el caso de
Administraciones Locales.

Tambin debemos a Roma el primer censo hace 2500 aos en la primera poca
de Roma y en tiempos de la monarqua de Servio Tulio. El censo divida a la poblacin
segn sus rentas, por lo que estamos probablemente ante un enfoque censal de fines
impositivos (actualmente se usa para realizar estudios estadstico de variables de la
poblacin). Aunque existen claras diferencias entre el censo y el padrn, hemos de
tener en cuenta que el censo es origen comn a ambos.

Vemos que en Roma nacen numerosos elementos que van a ir asociados hasta
nuestros das a la ciudad y por lo tanto al tipo de datos que un municipio actual va a
necesitar.

A vista de pjaro no vemos grandes diferencias entre aquella Atenas y esta
Roma. Como en aquella las calles con denominacin sern escasas, aunque ms
numerosas, mejor documentadas. Como en aquella no existe una predefinicin
urbanstica y las calles son estrechas, quebradas o serpenteantes formando una
maraa de callejuelas que dan cuenta del origen agrcola de la ciudad. Su orografa
tampoco es llana y tambin dispone de un rio (Tiber) como sucede con Atenas.

Acercndonos, sin embargo, veremos algunos hitos y caractersticas de Roma
que son de inters para avanzar en nuestra historia de los nomencltores, tomados en
gran medida del Coriosum Urbis Romae que se public en 1878 por Alexander Riese:

- En el ao 73 d.C se miden todas las calles (viae) de la ciudad de Roma que daba un
montante de 85 Km. Roma tena 423 calles y 37 puertas. Sus calles tenan una anchura
de entre 4,80 y 6,50 metros, aunque a la entrada de roma su anchura total pasaba a
ser de 12 metros (autopistas de acceso a aglomeraciones). Pensemos que Roma
Imperial tena casi 50.000 edificios tal y como hoy los concebimos y unas 2000
residencias individuales y que pese a que los romanos solan disear las ciudades para
no ms de 50.000 habitantes, Roma lleg a tener un milln de ellos.


- El origen agrcola se puede ver en la divisin de tipos de calle que haba inicialmente:
- Itinera: Caminos exclusivo de peatones
- Actus: Camino exclusivo de carros
- Viae: Camino para dos carros que se pueden cruzar o circular en paralelo.

- Slo son consideradas como calles con nombre en el interior de la muralla dos
situadas en la zona del Foro: Va Sacra y Va Nova. Entre la muralla y el final de la
ciudad se da nombre a otras veinti nueve, la mayora de las cuales es el inicio de una
calzada romana: Via Traiana, Appia, Latina, Labicana, Praenestina, Tiburtina,
Nomentana, Salaria, Flaminia, Aemilia, Clodia, Lauarentina, Valeria, Aurelia, Campana,
Ostiensis, Portuensis, Ianiculuensis, Ardeatina, Setina, Tiberina, Quintia, Cassia, Gallica,
Cornelia, Triumphalis, Patinaris, Asinaria y Ciminia. (el 7% de las calles de Roma).

- La ciudad tiene ocho puentes todos con denominacin: Aelius, Aemilius, Aurelius,
Milvius, Sublicius, Fabricius, Cestius, Pons Probi.

- Once foros: Forum Romanum, Fora of Caesar, of Augustus, of Nerva, of Trajan, of
Ahenobarbus, Forum Boarium, Forum Suarium, Forum Pistorum, Forum Gallorum,
Forum Rusticorum

- Diez baslicas (tribunales, normalmente situados en el foro): Julia, Ulpia, Paula,
Vestilia, Neptunia, Matidia, Marciana, Vascolaris, Floscellaria, Constantiniana

- Once baos pblicos: Thermae de Trajano, Titus, Commodus, Antoniniana, Caracalla,
Suranae, Agrippa, Severus, Diocletian, Constantine, Septimius Severus



Del nomencltor: Aspecto de la antigua ciudad de Roma de Kiepert y Huelsen de 1923

- Haba tipos de va diferentes, como por ejemplo los pasajes angiportus, los
senderos semitae o las cuestas clivi. Las cuestas solan tener un trazado en forma
de zig-zag y como ejemplos tenemos la clivus Capitolinus, la clivus Argentarius, clivus
Sacer, clivus Palatinus, clivus Victoriae, clivus Orbius

- En cuanto a topnimos encontramos los diecinueve acueductos: Aqua Traiana,
Aniena, Aniena II, Marcia, Claudia, Herculi, Caerulea, Julia, Augustea, Appia, Alsetina,
Ciminia, Aurelia, Damnata, Virgo, Tepula, Severiana, Antoniniana, ALexandrina y las
soete colinas Caelian, Aventine, Tarpeian, Palatine, Esquiline, Vatican, Janiculum.

Adems repartidos por la ciudad haba cientos de santuarios, veintiocho
bibliotecas, dos circos, dos anfiteatros, dos coliseos, dos mercados y tres teatros.



La ciudad sin duda tena muchos ms elementos de localizacin que Atenas,
pero tambin debemos de pensar que Roma lleg a albergar, como ya hemos
comentado, a un milln de habitantes durante la poca de Augusto. Es posible que en
estas circunstancias no hubiese an un callejero (suficientemente denso) de uso
comn, pero por la Administracin de Roma y gentes notables si se utilizara. Un
ejemplo de ello es un colgante de esclavo encontrado en Roma. La Via lata, nombrada
en la inscripcin, era una calle daba nombre a la sptima de las catorce zonas en que
Augusto dividi Roma (los primeros distritos):

Detenme porque huyo, y vulveme a la calle ancha (VIA LATA), a casa de Flavio mi dueo

En esta poca las calles de Roma fueron siendo empedradas progresivamente,
muchas de ellas con aceras margines, con bombeo y pasos de peatones que hacan
las veces de badenes y posibilitaban no mojarse a las personas al cruzar en tiempo de
lluvia.



Detalle de margin y bloque de paso de cebra al fondo. Foto Javier J. Boix.

Hasta este momento se seguira empleando el cerca de o junto a . para
indicar un punto o explicar una ruta. La ciudad, an as era menos catica que Atenas y
tena muchos ms elementos en los que apoyarse, de manera que al menos una gran
parte de la ciudad el problema de las direcciones habra quedado bastante resuelto y
estaba generalizado el uso de la denominacin de un nmero creciente de calles que
iban tomndolo administrativa o popularmente.

En el ao 200, en la poca de Septimo Severo ya tenemos la constatacin
fehaciente de lo que puede ser considerada la primera gua municipal o plano
topomtrico de la ciudad. Los aproximadamente 1200 fragmentos digitalizados y
encontrados a partir del S XVI se estn estudiando y poniendo en puzle para lograr la
mejor reconstruccin visual posible gracias a la Universidad de Stamford. Meda en
origen 18 x 13 metros y estaba realizado sobre 150 losas de mrmol tallado a escala.
Se situaba sobre una pared de Roma y fue destruido durante la Edad Media como
material de construccin o para la fabricacin de cal.



Proyecto de reconstruccin del primer plano topomtrico (Universidad Stamford):
Puede consultarse digitalmente en : http://formaurbis.stanford.edu/docs/FURslabmap.html

En el plano de ciudad podemos ver el reflejo de un nivel de detalle y geometra
rigurosa desde luego no visto antes. Se detallan columnas, puertas y la medicin sera
posible sobre l. Para nuestro estudio es sumamente importante la aparicin de una
rotulacin exhaustiva de la ciudad indicando topnimos, nombres de vas y elementos
de inters de la ciudad. Sin duda el ciudadano uso este plano para orientarse en el
siglo III de nuestra era.

El hecho de que el potencial militar romano fuese enorme nos hacen pensar en
los mapas de carreteras, que existiran tambin en la antigua Roma y otros ms de uso
exclusivo militar sin duda.

Con respecto a las carreteras podemos decir que an cuando la orientacin en
las ciudades ya era en muchas zonas posible con la calle, la numeracin no exista, no
obstante es posible que usasen el nombre de su habitante o bien se basaran en las
puertas existentes para orientarse y llegar al destino en muchos casos. Si bien en la
ciudad los romanos no inventaron la numeracin s que lo hicieron en las carreteras.
Cada 1468 metros (milla romana) colocaban un miliarium, que era un bloque
redondo de piedra que expresaba la distancia total al punto de partida y cada 30 Km se
situaba una Mansion a modo de posada. Los caminos los haba vecinales y militares.


Nace pues aqu el concepto de punto kilomtrico que en nuestras carreteras sigue
sirviendo de completa direccin.

Llegamos as a un punto total de conexin entre una direccin actual y una
histrica. Podemos decir que en este momento acaba de nacer el concepto de
direccin actual. Estamos en el S III o IV de nuestra era.

Calzadas romanas de Hispania



El Miliarium Aureum (foto MM) o punto origen de las calzadas romanas y la antigua placa de 1950 del
Km. 0 de Madrid (ya sustituida) origen de las carreteras en Espaa .

EDAD MEDIA Y RENACIMIENTO

EDAD MEDIA

La Edad Media representa para la topografa, como para la mayora de las
ciencias, un retroceso en cuanto a conocimiento. En la Pennsula slo se comienza a
ver una salida cientfica al final de la etapa.

Veamos algunos hechos histricos que nos ayudarn a entender el periodo:

Tras la cada del Imperio Romano de Occidente (recordemos que el de Oriente
o Bizantino se produce en el S XV y dicho acontecimiento es prcticamente coetneo
de nuestros Reyes Catlicos) la Hispania romana es invadida por pueblos procedentes
de Germania (Vndalos, Alanos, Suevos y Visigodos) y son estos ltimos los que crean
el primer reino de la Edad Media en Toledo que con Leovigildo prcticamente se hizo
en el S. VI con toda la Pennsula Ibrica. Una serie de malas cosechas provoc la
hambruna en el reino, de manera que en el 702 Witiza lleg al trono y fue el


enfrentamiento entre sus hijos por la sucesin (Rodrigo le sucedi, pero no fue
aceptado) lo que provoc que los hermanos de este pidiesen ayuda a los musulmanes
que derrotaron a Rodrigo en la batalla de Guadalete, lo que supuso el fin del Reino
Visigodo de Toledo y la expansin musulmana. En la poca Visigoda tenemos que
tener en cuenta el gran apoyo que estos reciban de la Iglesia (los concilios se
realizaban en Toledo). Adems los grandes pensadores de esta poca sern
eclesisticos, como nuestro patrono San Isidoro que escribi sus Etimologas, la
primera gran enciclopedia de la Historia. En ella aparecen los tpicos mapas
diagramticos de la poca medieval en forma de T con la representacin de tres
continentes separados (T) y rodeados con una O que representa el ocano y su
orientados al este en su parte superior. La economa en esta poca estaba basada en la
agricultura y ganadera latifundista cayendo la artesana y el comercio a lo
estrictamente necesario.

Primera impresin de las etimologas de S. Isidoro en el que aparece el rasgo diagramtico tpico de la
cartografa del Medievo sin fundamento geomtrico alguno.



A partir de ese momento comienza la dominacin musulmana en Espaa pero
basada en una concepcin urbanstica similar (Mezquita, recinto amurallado, palacios
oficiales) de manera que la dominacin rabe representa ms un hito arquitectnico
y de materiales que cambio de influencia urbanstica. Como dice Mazen Suleiman
Shinaq en su tesis doctoral de Arquitectura, para los musulmanes el Islam es el centro
de todo y este no establece criterios con respecto a la ciudad. En general la ciudad
tiene su centro en la Mezquita. En varias ocasiones se ha hablado sobre su trazado
fsico y su trama, la cual estaba dispuesta de la siguiente forma: en el centro la
mezquita principal y la casa del califato formando una unidad urbanstica, a su
alrededor los mercados en muchos casos especializados, los khans, los baos pblicos
y alhndigas, los barrios residenciales, los cementerios (maqbara) fuera del recinto, a
las puertas de la ciudad sin vallado alguno, hornos y musall (lugar dedicado a la
oracin en las fiestas religiosas ya que, al ser multitudinarias, en la mezquita principal
no caben todos los creyentes). Serjeant (1983).

La mayora de los castra (campamentos militares romanos), derivaron en
ciudades con sus dos vas principales (cardo y decumano). Como ejemplos podemos
destacar Emerita Augusta, Salmantica, Toletum, Corduba, Carthago Nova, Saguntum y
Tarraco.

En general se produce un abandono de la ciudad para generarse una poblacin
mayoritariamente rural protegida por un seor feudal que yergue un castillo y tambin
un templo en torno al cual la poblacin se va desarrollando paulatinamente (pensemos
en una gran parte de los pueblos de Espaa). En este contexto volvemos a un orden
centralizado cuyo eje es el templo y la fortaleza en cuyo rededor crece arbitraria la
poblacin. Segn Julio Caro Baroja en su libro Los ncleos urbanos de la Espaa
cristiana medieval, se iran creando espacios mercantiles, y comerciales a las afueras
que an de inicios geomtricos inexactos se ira configurando regularmente y que
dara lugar a las plazas de la poblacin.

Por su parte durante la dominacin rabe se hace importante el Al-urf que
basado en principios de sentido comn orient las normas urbansticas de las
ciudades, como decimos tendentes a la defensa de lo intimo. Por ejemplo las calles
tenan que tener un ancho mnimo basado en el transporte habitual y la posicin de
ventanas y puertas tena normas. En resumen lo fundamental del urbanismo islmico
es su carcter intimista.


Documentos de Wingaerde y Texeira en el que todava se poda ver que existan zonas de la muralla de
Madrid en buen estado incluso en pocas ms recientes (Renacimiento).



Youseff (1993) Calles principales y fondos de saco. Ventanas y puertas
Fte: Mazen Suleiman


Tambin aparecen en la Edad Media tarda planos de ciudades como la de
Constantinopla de Cristoforo de Buondelmonti que es el plano ms antiguo
conservado de la ciudad de Estambl y publicado en su libro Insularum Archipielagi.

Plano de Constantinopla en 1422.

En 1493 Hartmann Schedel realiza una obra histrica religiosa con ilustraciones
de Michael Wolgemut (maestro de Durero) en sus Schedelsche Weltchronik (Crnica


de Nueremberg) en la que aparecen diversos planos de poblaciones importantes de la
poca, incluida la propia Constantinopla otra vez, pero en este caso se trata ms bien
de ilustraciones representativas del aspecto general en los que la precisin y la
identificacin de puntos de inters como plano callejero se hacen complicadas.

Aspecto de Florencia en las Crnicas de Nuremberg.

En cuanto a Madrid podemos ver que siempre y debido al rio Manzanares ha
habido pobladores, desde la prehistoria, pasando por el hallazgo de Villas romanas, no
obstante, an cuando existen referencias humanas desde tiempos prehistricos lo que
podemos considerar su germen se encuentra en esta poca, aunque tambin es
posible que ya existiese alguna aldea pequea. Toledo era una ciudad importantsima y
era sumamente necesaria tenerla protegida de los posibles avances de las tropas
cristianas del norte, de manera que el emir Muhammad I, decide crear en Madrid en el
S. IX, es decir, un siglo despus de la llegada de los musulmanes a la pennsula un
castillo como complemento a otras atalayas creadas al efecto y formando la defensa
avanzada de la ciudad de Toledo. Este origen viene refrendado por numerosos


estudiosos como Lev-Provenal o Jaime Oliver Asn. Es este ltimo autor, fallecido en
1980, en su libro historia del nombre de Madrid, publicado por el Consejo Superior
de Investigaciones Cientficas el que dice: Matrice ha sido el primer nombre de la
Villa, un Madrid premusulmn, y que haca alusin al arroyo (madre, madre de aguas,
matriz de aguas) que corra por el vallejo que actualmente es la calle de Segovia. Este
nombre primitivo debi, con la invasin islmica, cambiar a Mayrit, formado por la
palabra rabe mayra (madre, matriz) y el sufijo iberorromnico "it". Tras la reconquista
Matrice y Mayrit (Magerit en forma castellanizada) se convertira en Matrit, nombre
del cual todava conservamos gentilicio los matritenses o madrileos.

Segn los estudios del doctor Manuel Montero y Cristina Segura, parece ser
que entorno al generado Alczar musulmn se fue estructurando una ciudad
musulmana (entre la plaza de la Armera y la puerta de Moros).

Restos de la muralla rabe junto a la catedral de la Almudena (al-mudayna)

Madrid es a partir de ese momento y prcticamente hasta el S XIX una
evolucin en crecimiento de la ciudad original guiada por las diferentes tendencias
arquitectnicas en su paisaje. La Edad Media ha dejado en Madrid importantes
monumentos, como el monasterio de los Jernimos (mandado hacer por los Reyes
Catlicos), la capilla del Obispo y la torre de los Lujanes en la plaza de la Villa (todas a
caballo entre el Gtico y el Renacimiento). En cualquier caso se trata de un gtico
tardo y adems austero y tendente al uso de materiales econmicos basados en la
arquitectura mudjar. La ciudad es reconquistada por Alfonso VIII junto a Toledo poco


despus de morir San Isidro y otorga fuero a la ciudad (S XIII), constituyendo estas las
primeras ordenanzas municipales de Madrid.

Adems el creciente desarrollo de Madrid obliga a que el arroyo del que se
abasteca fuese insuficiente, de manera que se llevaron a cabo obras para encauzar
fuentes y completar el abastecimiento. Sistema que perdur hasta el S XIX con la
creacin del Canal de Isabel II. Como curiosidad decir, que el gentilicio popular gatos
proviene de cmo escalaban los muros de la muralla los soldados cristianos de Alfonso
VIII en la reconquista de la ciudad.

Idealizacin de J.M Castellanos de Madrid en los tiempos del fuero. Por orden :
1 Santa Maria,2 San Nicolsa,3 San Salvador, 4 San Juan,5 San Miguel de Sagra,6 San Pedro,7 San
Andrs,8 San Miguel de los Octoes,9 San Justo y 10 Santiago.

Desde el punto de vista de relaciones nominales los portulanos no slo
representan la necesidad de la vuelta a una cartografa precisa, sino que en ellos es
bsica la orientacin (el uso de la brjula ya se haba extendido) y el conocimiento de
los nombres en la costa, por lo que son muy profusos en la indicacin de estos
topnimos sobre el mapa.



Ejemplo de un portulano del S XIV en cuya fabricacin, la escuela mallorquina fue referente

Tambin los itinerarios de peregrinacin dieron lugar incluso a ciudades
(Logroo) y a numerosa informacin valiosa para el peregrino. Por ejemplo Aymeric
Picaud en el S XII escribi su Liber Peregrinationis del Codex Calixtinus. En esta se
divide el Camino de Santiago en 13 etapas en las que se describen paisajes, lugares,
ciudades, pueblos y recomendaciones. Se trata del primer concepto de nomencltor
del viajero (ver extracto ms abajo) o gua de viajes que encontarmos desde la poca
romana. Los portulanos, as como estas nuevas guas nos dan una pista de que la
oscuridad medieval termina y una era nueva empieza: El Renacimiento.

Captulo III del Liber Peregrinationis : Los nombres de los pueblos del camino
De Somport a Puente la Reina, stas son las localidades que seencuentran en la ruta jacobea: la
primera es Borce, al pie del monte, en la vertiente de Gascua; viene luego, cruzada la cima del
monte, el Hospital de Santa Cristina, despus Canfranc, a continuacin Jaca, luego Osturit,
despus Tiermas con sus baos reales, que fluyen calientes constantemente. Luego Monreal y
finalmente se encuentra Puente la Reina. En cambio, en el Camino de Santiago que desde Port
de Cize conduce a la baslica del santo en Galicia, se encuentran las siguientes localidades ms
importantes: en primer lugar, al pie del mismo nombre de Cize y en la vertiente de Gascua,
est la villa de Saint-Michel, luego, pasada la cima del monte, se encuentra el Hospital de
Roldn, luego la villa de Roncesvalles, luego se encuentra Viscarret, despus Larrasoaa, luego


la ciudad de Pamplona, a continuacin Puente la Reina, despus Estella, frtil en buen pan y
excelente vino, as como en carne y pescado, y abastecida de todo tipo de bienes. Vienen luego
Los Arcos, Logroo, Villarroya, la ciudad de Njera,Santo Domingo, Redecilla, Belorado,
Villafranca-Montes de Oca, Atapuerca,la ciudad de Burgos, Tardajos, Hornillos, Castrojeriz, el
puente de Itero, Frmista y Carrin, que es una villa prspera y excelente, abundante en pan,
vino, carne y todo tipo de productos. Viene luego Sahagn, prdigo en todo tipo de bienes,
donde se encuentra el prado donde, se dice, que antao reverdecieron las astas fulgurantes
que los guerreros victoriosos haban hincado en tierra, para gloria del Seor.
Viene luego Mansilla, despus Len, ciudad sede de la corte real, llena de todo tipo de bienes,
luego est rbigo, la ciudad de Astorga, Rabanal, por sobrenombre "Cativo", luego el puerto
del monte Irago, Molinaseca, Ponferrada, Cacabelos, despus, Villafranca, en la embocadura
del valle del ro Valcarce, y Castrosarracn, luego Villaus, despus el puerto del monte Cebrero y
en su cima el hospital, luego Linares de Rey y Triacastela, en la falda del mismo monte, ya en
Galicia, lugar donde los peregrinos cogen una piedra y la llevan hasta Castaeda, para obtener
cal destinada a las obras de la baslica del Apstol. Vienen luego San Miguel, Barbadelo,
Puertomarn, Sala de la Reina, Palas de Rey, Lebureiro, Santiago de Boente, Castaeda,
Vilanova, Ferreiros y a continuacin Compostela, la excelsa ciudad del Apstol, repleta de todo
tipo de encantos, la ciudad que custodia los restos mortales de Santiago, motivo por el que est
considerada como la ms dichosa y excelsa de las ciudades de Espaa.

UN EJEMPLO DE NOMENCLATOR DE POBLACIONES DEL CAMINO DE SANTIAGO DEL S XII

RENACIMIENTO

Como todos sabemos, el Renacimiento constituye la salida del oscurantismo
medieval. Representa la vuelta a la concepcin clsica de las formas. Se retoman los
conocimientos de los sabios griegos y romanos.

En el urbanismo se pretenden nuevos planteamientos de diseo, pero sobre la
base de la ciudad medieval ello se presenta complicado, de manera que son ms los
proyectos y las idealizaciones que las ejecuciones realmente llevadas a cabo. Es
relevante en cuanto a estas idealizaciones el seguimiento que de las teorizaciones de
Vitrubio se proyectaron. Entre ellas la nica que se llev a cabo de forma completa fue
la de la ciudad italiana de Palmanova que segua los cnones marcados por el
arquitecto clsico y en el que se consideraban aspectos tan modernos como la
agradabilidad del entorno (por supuesto la tendencia eran figuras geomtricas con el
crculo [perfeccin geomtrica griega] como elemento basal).


Palmanova (Italia) en la actualidad (En realidad comenz a construirse en 1593)

En el ltimo periodo de la Edad Media y ahora en el Renacimiento, Madrid va
cobrando posiblemente por su centralidad, una creciente importancia, de manera que
se realizan obras religiosas y tambin administrativas Paralelamente se promulgan
disposiciones centradas en el adoquinado de las calles.

En cuanto a planos de ciudades y dado que los cartgrafos de la poca haban
conseguido vastos conocimientos en cuanto perspectiva y proyecciones, esto se deja
influir en los documentos que aparecen. Destaca entre ellos el plano de Jacopo Barbari
que alrededor de 1500 realiz un plano de Venecia de gran detalle y exactitud, el cual
tiene unas dimensiones de 2,82 m x 1.39 m construido sobre un puzle de 3x2 tablas
grabadas. Ms adelante los procesos de grabado sobre cobre refinaran la tcnica de
grabado sobre madera.

En cualquier caso se trata de planos que todava tardaramos en ver en Madrid
y dan una idea de cmo el Renacimiento Italiano representa un hito artstico y
cientfico dentro de esta poca histrica.



Plano de Venecia de Jacopo Barbari Ao 1500

A mediados del S XV en la pennsula existan los reinos de Portugal, Castilla y
Len, Granada, Navarra y Aragn. El Renacimiento en Espaa tiene por costumbre
darse cronolgicamente iniciado al tiempo que se concluye la conquista en 1492 por
los Reyes Catlicos del Reino de Granada, es decir en el S XVI

Los avances en teora cientfica, como ya se apunt al inicio de este periodo son
inmensos. Se produce aqu una autntica revolucin geomtrica. Podemos destacar el
Theoricae novae planetarum de Peuerbach en 1472 que inclua una nueva tabla de
senos o el Triangulis omnimodis en 1490 y del mismo autor, los trabajos aritmticos
de Chuquet, la Summa de arithmetica, geometrica, proportioni et proportionalita de
Luca Pacioli o el De revolutionibus orbium coelestium de Coprnico en 1593, adems
de otros estudios ligados a la perspectiva como el de Piero della Francesca en su De
prospectiva pingendi de 1478. Es el punto de partida, la base necesaria de
conocimientos a las que muchos gegrafos tambin contribuyeron y sobre todo que
supieron utilizar para establecer las bases de la cartografa moderna.

A lo largo de este recorrido histrico que venimos haciendo se ha intentado
hacer referencia a la ciudad de Madrid, siempre que fuese didctico para la
comprensin ltima de lo que se pretenda transmitir entendiendo que se trataba de la


historia de los nomencltores y que Madrid no podemos considerarla realmente
existente como centro de importancia hasta la Edad Media, en la que efectivamente se
inicia su nacimiento estratgico y avance como ciudad de situacin privilegiada. A
partir de ahora y aunque no dejemos de obviar determinados documentos que
podran influir decisivamente en los nuevos conceptos de planos de ciudad en otros
lugares, intentaremos centrarnos en ver la evolucin de los mismos en nuestra ciudad
mediante la cartografa que fue apareciendo hasta que lleguemos al S XIX. Vamos a
ver esta evolucin:

Extracto de plano de Madrid de 1622 de Antonio Mancelli Fte: Comunidad de Madrid/Ayuntamiento de
Madrid
[Villa de Madrid. Corte de los Reyes Catlicos de Espaa, de Gmez de Mora]



Extracto del plano de Madrid de Pedro Texeira de 1656 a escala 1:1800 con perspectiva caballera.

Realizado por Carlos y Fernando de Grunenbergh en 1668 para el proyecto de navegabilidad del
Manzanares hasta el Tajo.- Fte IGN


Plano de Madrid de Madrid Nicols de Fer. Ao 1706. Se puede apreciar la codificacin numrica para
situar puntos de inters de la ciudad Fte: Comunidad de Madrid/ Ayuntamiento de Madrid

Mapa del rio Manzanares de 1724 de Lucas Constant, Ortiz de Zugasti con abundante toponmia. Fte
Comunidad de Madrid/Ayuntamiento de Madrid



Detalle de plano de Madrid 1730 de George Matthaus publicado en Alemania en el que aparece
numerosa toponmia urbana en espaol, latn y francs.- Fte IGN

Extracto de plano de proyecto de alcantarillado del topgrafo ingeniero Jose Alonso de Arce de 1734
siendo Alcalde de Madrid el Marqus de Vadillo Fte: Comunidad de Madrid / Ayuntamiento de Madrid


Accurater Grundis der Konigl. Spanischen Haupt und Residentz Stadt Madrit mit denen Prospecten des
Knige. Schlosses und andern lust Gebauen
[Plano de poblacin realizado en Alemania de Madrid (1735) Fte. IGN]

No olvidemos la necesidad de cartografa realizada a marchas forzadas de las posesiones americanas
que eran precisas para su desarrollo. En la imagen las ciudades de Popayn Colombia) y Lima(Per) de
Toms Lpez en su Atlas de la Amrica septentrional y meridional de 1758 Fte: Catlogo de Carmen
Manso Porto


Extracto del plano geomtrico de Madrid de 1785 de Toms Lopez. Quedaban 23 aos para que se iniase
la guerra de la Independencia contra los franceses (1808-1814), en la que Madrid jugara un importante
papel. Fte : IGN

(Ver este plano conjuntamente con las figuras siguientes)


Plano de la Villa y Corte de Madrid en 64 lminas, con barrios y cuarteles realizado por Fausto Martnez
de la Torre y Josef Asensio en la Imprenta de Don Joseph Doblado en 1800 (Ntese la numeracin
catastral de la Visita General) Fte: Comunidad de Madrid/Ayuntamiento de Madrid

El trabajo de Fausto Martnez de la Torre y Josef Asensio es el primer
documento de aspecto realmente actual de nomencltor urbano. Se trata de una serie
de lminas encuadernadas con los barrios de Madrid y diccionario de nombres
geogrficos, unos de callejero y otros de puntos de inters, todos ellos
georreferenciados a travs de la lmina en la que aparecen. Se trata de un trabajo muy
avanzado a su poca, ya que por poner un ejemplo, el primer documento encontrado
para Londrs data de 1854 Atlas de Londrs ilustrado de Collins (realizado por
Richard Jarman) y aunque su concepto es ms evolucionado y su aspecto ms parecido
al de una gua urbana, no podemos obviar la diferencia en el tiempo entre ambas
publicaciones.



Extracto del Atlas de Londres de Richard Jarman.

Es importante destacar que a finales del XVIII nace la litografa, inventada por el
dramaturgo alemn Aloys Senefelder que supuso el origen de producciones en masa
de dibujos y que fue bautizado inicialmente como impresin qumica.

ANTECEDENTES PRXIMOS

SIGLOS XIX y XX

Es evidente que el S XIX y sobre todo el XX, con el empuje cientfico del
Renacimiento y sus numerosas guerras en el S XX que contribuyeron a importantes
avances tcnicos suponen el definitivo acelern que necesitaba la cartografa. Durante
esta poca se mejoran todo tipo de tcnicas de proyecto y metodologa como de
produccin cartogrfica. Desde la invencin de la cmara lcida de William Hyde


Wollaston (basado en las teoras de Kepler) precusor de la fotografa de Nipce y
Daguerre, pasando por la invencin del avin de los hermanos Wright, hasta el
nacimiento de las tcnicas Offset (evolucin de la litografa gracias a la inclusin de los
cilindros por el estadounidense Ira Rubel gracias a un error a principios del S XX) todo
lo que se inventa es aprovechado en pro de la tcnica. No olvidaremos la aparicin de
los ordenadores entre los periodos 1941 (Inventor: Konrad Zuse [Alemania]), 1944
(COLOSSUS [Inglaterra]), 1946 (ENIAC [EEUU]) y 1949 (EDSAC [Inglaterra]). Al mismo
tiempo, la ingeniera en todas sus ramas toma un puesto preponderante en la sociedad
en un mundo que comienza a ser cada da ms globalizado, lo que contribuye al
avance tambin de la ingeniera topogrfica y cartogrfica.

Continuemos viendo cmo evolucionan los planos de nuestra ciudad.

Extracto sur del mapa militar de Madrid del ejrcito francs en la guerra de la independencia (1808) en
la que se ven las posiciones de bombardeo. Autor: Jos Carlos Mara Bentabole.- Ft: Comunidad de
Madrid/Ayuntamiento de Madrid


Extracto sur del plano de Madrid de 1812 de Juan Lpez. Primera constitucin espaola (Cortes de
Cdiz). En 1819 se inaugurar el Museo del Prado- Fte Comunidad de Madrid/Ayuntamiento de Madrid

Ver en conjuncin con las imgenes siguientes.


Nomencltor de Madrid de 1843 de la imprenta de Santiago Trujillo y realizado por Jos Quiros, en el que
adems de las calles por orden alfabtico aparecen los cuarteles, distritos, Juzgados de primera
instancia, Alcaldas constitucionales y una resea de los 89 barrios del momento. Se trata de un
nomencltor no geogrfico en el que las calles se explican en vez de aportarse el plano correspondiente.
En 1834 el Marqus de Pontejos modific la forma de numerar la ciudad. Fte- Comunidad de Madrid /
Ayuntamiento de Madrid

Creo interesante resear, que aunque no fueron las nicas desamortizaciones
que se han producido en Espaa, las de Jos I entre 1808 y 1813 (para sostener la
guerra de la Independencia) y la de Mendizabal entre 1835 y 1844 (para sostener las
guerras carlistas) si fueron las ms perjudiciales para Madrid. Siempre que el Estado
tiene grandes deudas con grandes intereses que pagar suele necesitar de medidas
injustas para la sociedad que lgicamente se intentan vender como algo bueno. En
Madrid el urbanismo se vio fuertemente alterado, desapareciendo grandes obras y
edificios que si hubiesen llegado hasta hoy seran autnticos iconos. Jos I hizo
desaparecer los conventos de Mostenses, San Bernardino, Santa Clara, Santa Catalina
de Siena, Santa Ana, Pasin y las iglesias de San Martn, San Juan, San Miguel de los
Octoes, San Ildefonso, San Gil y Santiago. Por su parte Mendizabal destruy los de
Merced, San Felipe el Real, Victoria, capuchinos de la Paciencia, San Basilio,
Magdalena, San Felipe Neri, Baronesas, ngeles, Constantinopla, monjas de Pinto,
Recoletos, monjas de Vallecas, Caballero de Gracia, Santa Brbara, Trinidad,
Agonizantes de San Camilo, Portacoeli y el Noviciado de los Jesuitas. La mayora de
estos suelos en el caso de Mendizabal fueron adquiridos por propietarios rentistas que


realizaron edificaciones de baja calidad y carentes de servicios con el fin de arrendarlas
al empobrecido tejido social madrileo.

Se trata de una reduccin realizada por Francisco Coello y Pascual Madoz en 1848 a partir del plano a
escala 1/1.250 realizado por Juan Merlo, Fernando Gutirrez y Juan Ribera entre los aos 1841 y 1846.
La poblacin de Madrid en 1845 era de 206.714 habitantes Fte : IGN

Jos I no todo lo hizo mal, por su parte abri espacios en el laberntico trazado
urbano para despejarlo (Plazas de Santiago, San Martn, San Miguel, Ramales, Santa
Ana y Mostenses y la apertura del espacio de la Plaza de Oriente, que no se llevara a
trmino hasta mucho despus (1850 con la inauguracin del Teatro Real). Tambin
realiz cementerios a las afueras de la ciudad mejorando la salubridad existente. Por
su parte y tras la guerra de la Independencia muchos espacios tuvieron que ser
reconstruidos o puestos en orden (especialmente el Parque del Retiro).



Mapa del IGN de 1853 provincial realizado por Tte. Coronel Francisco Coello - Atlas de Espaa Fte: IGN

Completo plano nomencltor de Madrid de 1866 realizado por los por los ingenieros de caminos D. Juan
Merlo , D. Fernando Gutirrez y D. Juan de Ribera para el Ayuntamiento de Madrid Fte Ayuntamiento
de Madrid


Mapa de fertilidad de suelos o eufomtrico de Madrid y alrededores de la Junta de estadstica de 1867
con perfiles Fte IGN

Fragmento de hoja parcelaria realizada por el cuerpo de topgrafos del Instituto Geogrfico y Estadstico
de 1875. Un plano de una calidad absolutamente sobresaliente Fte: IGN


Facsimil del manual del madrileo y del forastero de Fernndez de los Rios de 1876. Con el auge de los
manuales del forastero se realizarn guas tursticas que contenan vistas, planos, historia y
descripciones de puntos de inters Fte: Facsimil de todocolecciones.net

En el periodo 1873-1874 tiene lugar el corto periodo de existencia de la I
repblica que va desde la abdicacin de Amadeo de Saboya hasta la restauracin
borbnica del hijo de Isabel II (Alfonso XII). En el Madrid de 1887 la poblacin era de
400.917 personas y en 30 aos haba aumentado un 42%. Madrid sigue siendo una
ciudad con graves problemas urbansticos, pero que mejora da a da. En las
postrimeras del siglo XX, Madrid se convierte ante todo en una ciudad cultural en la
que la ruina de la perdida de las ltimas colonias americanas y asiticas da cuenta del
fin de Espaa como gran potencia mundial.



Interesante muestra del futuro toponmico de las calles de Madrid. Plano de Madrid y alrededores del
Depsito de la Guerra de 1890 (Ocho aos antes de la prdida de Cuba, Puerto Rico y Filipinas) Fte: IGN

En el periodo 1900-1950 Madrid triplica su poblacin y en el periodo 1950-1970
la vuelve a duplicar. El Madrid actual que conocemos es pues en gran medida el
desarrollo urbanstico del siglo XX. Pensemos en el inicio del siglo XX como el tiempo
de las tertulias, zarzuelas y teatros. Un auge liberal que impregna la cultura y que
acaba en grandes hitos culturales como la generacin de 1898 y la de 1927 resultan
exponentes antagnicos con respecto a los desastres de lo poltico.

Efectivamente Espaa es desde el fin de la I Repblica hasta el fin de la guerra
civil una nacin convulsa en continuas sucesiones de disputas que impiden la
estabilidad necesaria para crecer econmicamente, lo cual, unido a la guerra y polticas
caticas hacen el resto para dejar a Espaa en condiciones muy inferiores a las de
Europa (a pesar de nuestra neutralidad en las dos guerras mundiales).



Calendario y gua de Madrid realizada por la imprenta de los Hijos de J. Ducazcal en 1895. Se trata de un
intento comercial de una especie de pginas amarillas de la poca con plano a escala 1:10.000. Fte:
Comunidad de Madrid / Ayuntamiento de Madrid

Almanaque y gua matritense de 1898 publicada por la tipografa de los suceores de Cuesta que incluye
Santoral, lista de todos los Santos, datos importantes sobre servicios pblicos, gua alfabtica oficial de
vas pblicas y plano de Madrid Fte: Comuniad de Madrid / Ayuntamiento de Madrid


En 1899 aparece la guia comercial de Madrid, que publica datos del Anuario del
Comercio. Se trata de una clara gua comercial publicitaria sin plano alguno. Publicada
por Bailly-Bailliere e Hijos.

Noticiero - Gua nueva de Madrid formada por Jos Mendez en 1900 en el que aparecen coloreados los
distritos existentes en el momento. Fte- Comunidad de Madrid / Ayuntamiento de Madrid


En 1902 y 1903 aparecen respectivamente el almanaque y gua matritense de la
imprenta de A. Santarn (es conocida otra edicin de 1908) y el Plano Gua de Madrid
Rayo Exprs de la Cruz. Exponentes de la creciente necesidad ciudadana de planos gua
y nomencltores de la ciudad.

Gua prctica de Madrid de 1906 de litografas Mndez con relacin de distritos representados en el
plano mediante iniciales y dos cuadros de estados de superficie y poblacin. Se trata de una
completsima gua del estado de la ciudad de Madrid de la poca Fte: Comunidad de Madrid /
Ayuntamiento de Madrid.


Plano de 1914 del Ministerio de Gobernacin de Joaqun Gutierrez con el nomencltor de servicios el
detalle de servicios de beneficencia pblica y privada de la ciudad. Fte: Comunidad de Madrid /

Plano de Madrid para orientacin del viajero se cree que de 1916 de Guillermo Trniger & C con la
indicacin en plano de las lneas de tranva, lo que constituye una novedad en los planos gua. Fte:
Comunidad de Madrid / Ayuntamiento de Madrid.


Plano del ensanche de Madrid realizado por Ayuntamiento de Madrid. Plano del Ensanche y gua de sus
calles y plazas, formado por la Seccin de Investigacin y Registro Fiscal de 1922. Sistema nomencltor
de callejero incluyendo los cruces en inicio y final de la calle, sistema que se sigue utilizando en el
nomencltor actual. Fte: Comunidad de Madrid / Ayuntamiento de Madrid.


Plano de la compaa metropolitana de Madrid indicando las lneas de metro de la ciudad de 1930 Fte:
Comunidad de Madrid / Ayuntamiento de Madrid.

Plan general de extensin del Ayuntamiento de Madrid con las vas proyectadas y dems elementos de
inters para los fines de expansin y servicios de la ciudad de 1931 Fte: Comunidad de Madrid /
Ayuntamiento de Madrid



Plano de la Villa de Madrid del Ayuntamiento con distritos de 1945. Ntese como Vallecas al no
pertenecer al trmino no tiene rotuladas sus calles.- Fte: Comunidad de Madrid / Ayuntamiento de
Madrid.

Plan de ordenacin urbana de 1946 dirigida por el arquitecto Pedro Bidagor Fte: Comunidad de Madrid
/ Ayuntamiento de Madrid



Ordenanzas de edificacin de 1950 de la Comisaria de Urbanismo del Ayuntamiento. Fte: Comunidad de
Madrid / Ayuntamiento de Madrid.

Divisin territorial de 1955 del Ayuntamiento de Madrid.



La ciudad de Madrid ha sufrido profundos cambios en el periodo estudiado. Fte: Comunidad de Madrid /



Las guas de las editoriales PAMIAS Y DE ALMAX vienen acompaando a los madrileos y turistas
durante dcadas y an, por supuesto lo siguen haciendo.

LA REVOLUCIN GEOMTICA (1980 hasta 2000)

La Gerencia Municipal de Urbanismo del Ayuntamiento de Madrid (actual rea
de Gobierno de Urbanismo y Vivienda) nace como tal en el ao 1964 y su objetivo es
centralizar todo el aspecto urbano de la ciudad y por tanto entre sus departamentos se
encuentra el de cartografa.

A principios de los aos 80 se ve la necesidad de informatizar la ingente
cantidad de datos disponibles. Se debe de llevar a cabo una estructuracin de los
mismos para poder ser utilizados por los departamentos municipales. El proyecto es
iniciado bajo el entonces Jefe de Informatizacin de la Gerencia, Antonio Cermeo que
en vista del nacimiento de las tecnologas SIG, comienza a barruntar la necesidad de
ligar la informacin alfanumrica con una base de datos, que l llama grfica y que
contuviese el callejero.

As a finales de los 80 y principios de los 90 se selecciona el SIG ms acorde a
lo que se entendan las necesidades de la Gerencia y que en aquel entonces fue el
sistema SICAD Geomatics de Siemens, basado en un ordenador central H60 de 64 Mb
que soportaba hasta 53 usuarios. Sobre esta mquina haba dos copias de la BBDD
ideada inicialmente, una para uso en consulta y otro para actualizacin con una
capacidad inicial de almacenamiento de 11 GB.


Salidas por pantalla de diversas operaciones realizadas con SICAD en GMU (finales S XX).

Aparte de ello se tenan una serie de estaciones grficas llamadas WS2000
interconectadas en una red de area local para edicin cartogrfica.

Por otro lado el CETI (Centro electrnico del tratamiento de la informacin)
haba nacido a finales de los aos 70. En el ao 1980 se refunda como CEMI (Centro
Municipal de Informtica) para aumentar su capacidad operativa y agilizar las tareas
burocrticas. Es en la dcada de los 90 cuando se piensa en interconectar la GMU con
el CEMI (actualmente IAM Informtica Ayuntamiento de Madrid) con una lnea de 64K.
Aquel proyecto realmente no se llev a cabo y GMU e IAM trabajaron de forma
paralela aunque coordinadamente En el caso de CEMI se realizaron estudios sobre los
SIG SICAD y ARC-INFO con el fin de estudiar usos en los que estas tecnologas
resultasen rentables.



Hasta muy avanzados los aos 90 e inicios del 2000 la informacin prctica
usada para las aplicaciones municipales, exceptuando el Urbanismo y bomberos, fue la
alfanumrica que mensualmente era enviada mediante cintas y despus cartuchos
desde la Gerencia Municipal de Urbanismo al Centro Municipal de Informtica.

Visual Map de la compaa espaola Visual GIS Engineering tiene actualmente como producto estrella el
VISUALMAP INTERNET SERVER. Su Director general es el Ingeniero Topgrafo Fco Javier Bernardosy su
salida al mercado represent un acierto de adaptacin de nuevas tecnologas para el ciudadano.

En este el momento en el que comienzan su revolucin los PC, que sirven de
nuevas utilidades informticas a los usuarios, comenzndose a sustituir
progresivamente los terminales tontos por estos dispositivos. Es la poca en la que
nacen guas urbanas digitales para PC, entre la que podemos destacar en Madrid la de
VisualMap, que se hizo muy til para los ciudadanos de la poca. En este periodo el
CEMI impulsa el nacimiento del nomencltor metropolitano y aborda proyectos para
mejorar la codificacin postal.

Es en los ltimos aos del siglo XX cuando realmente se completa la unin entre
los datos de Urbanismo y los de Informtica, de manera que diariamente el
nomencltor propio se actualiza. Tambin se realiza por parte de informtica la
primera gua digital de Madrid para la recin estrenada pgina web municipal. Ello
obliga a disponer de un pequeo callejero en un servidor que se actualiza
semanalmente.



Paralelamente a principios del nuevo siglo nace SIGMA, el concepto distribuido
de I.G. del Ayuntamiento de Madrid, el cual dispone de una serie de nodos conectados
a una informacin cartogrfica central, sobre los que nacen distintas aplicaciones de
base georreferenciada / georeferenciable.

En la actualidad los sistemas de nomencltor se han ampliado creando el
nomencltor nacional y gestionando un nivel de informacin no slo en cuanto a
informacin del propio nomencltor, sino asociada al mismo de gran utilidad al estar
disponible para todo aplicativo conectado, al tiempo que BDC se interrelaciona de
forma directa con SIGMA. El circuito del nomencltor en Madrid se ha cerrado.

(Aspecto de aplicaciones sobre el SIGMA de Urbanismo)


Aspecto de la gua urbana municipal del Ayuntamiento de Madrid - 2012



3
NECESIDAD DE NOMENCLTOR

La Administracin Local, como otras administraciones y empresas de gran
tamao necesita disponer de una informacin actualizada de la realidad. Esa realidad
es bastante compleja y en el caso de los grandes municipios influye en factores como
la gestin de habitantes, el mantenimiento general de la ciudad, la organizacin de los
servicios sociales y asistenciales, el mantenimiento de orden pblico, control de la
circulacin etc. sobre una extensin muy amplia.

La mayora de las aplicaciones de gestin municipales tienen como elemento
comn la necesidad del conocimiento del lugar al que se asigna el evento (abstraccin del
mundo real asociado a una localizacin espacial.) a representar. As:

- El padrn municipal de habitantes representa la realidad de los ciudadanos de
un determinado lugar. Es preciso el conocimiento del lugar en donde habitan.
- Cualquier servicio de mantenimiento, como el de alumbrado, por poner uno
concreto, precisa el conocimiento de una determinada farola o en su caso
aproximacin al conocimiento de la situacin de la misma para solucionar una
determinada incidencia.
- Si los servicios sociales tienen que estudiar un caso determinado precisan entre
otros del conocimiento de la residencia o lugar en donde habita una
determinada persona (A veces una direccin puede ser tan compleja como
Furgoneta blanca SEAT frente al nmero 7 de la C/ Tucumn)
- Los servicios de emergencias. Cuando el SAMUR (servicio de emergencias
mdicas del Ayuntamiento de Madrid) tiene una salida la situacin de la misma


puede ser clave para la vida de alguien. Direcciones de cruces en este sentido
son habituales.
- Los servicios administrativos. Cualquier recibo o notificacin que deba de
realizarse a un ciudadano requerir de una correcta identificacin de dicha
notificacin a los servicios postales o para entrega en mano por parte de
inspeccin o polica.

El mantenimiento de ese elemento comn, en buena medida es
responsabilidad del propio Ayuntamiento quien se ha de encargar de su eficiencia y
exactitud. Adems de para su propio uso, la Administracin debe de poder
proporcionar esta informacin a otros Organismos y empresas privadas, cuya eficacia
dependa en gran manera de la bondad de dicha informacin.

En definitiva, el ciudadano, precisa para su interrelacin con el municipio de un
elemento del nomencltor, siendo responsabilidad de este el que dicho elemento sea
inequvoco. La motivacin de la existencia del nomencltor geogrfico de la ciudad no
es otro que la necesidad del hombre de comunicarse y localizarse, que siempre ha
existido.



El nomencltor de la ciudad deber contener todos aquellos elementos reales o
simblicos que puedan coadyuvar a una correcta identificacin de un lugar de la
ciudad. As tendremos como elemento principal el propio callejero, pero no habr que
olvidar los topnimos, los nombres populares, las divisiones, sean administrativas o de
cualquier otra ndole, as como puntos de inters sobre los cuales se pueda tener una
base ms o menos localizada que permita una ubicacin zonal, lineal o puntual de un
elemento concreto. Todo ello de acuerdo a un nomencltor geogrfico deber de
poder identificarse sobre cartografa en una relacin bidireccional que puede
establecerse con tecnologas bien diferenciadas.
El nomencltor de una ciudad adems debe de considerar elementos ajenos a
s misma puesto que cualquier ciudad mantiene una relacin con personas fsicas o
jurdicas que sin serlo de la ciudad misma, se relacionan con ella en un espectro
temporal mayor o menor (desde una multa de circulacin, hasta una fbrica cuya
matriz est en otras poblaciones, pasando por un inmueble en propiedad).

TIPOLOGA DEL NOMENCLATOR MUNICIPAL

Como hemos ido intuyendo en el apartado anterior, la repercusin que tiene la
actividad municipal de una gran ciudad no es comparable al de municipios menores. La
problemtica, al ser ms compleja y de mayor volumen, precisa de soluciones mejor
definidas y ms estructuradas cuyo fin ltimo debe ser hacer viable su mantenimiento
recogiendo al unsono las necesidades a las que deba dar respuesta. En un
nomencltor de un Ayuntamiento como el de Madrid se debern contemplar tres tipos
de (sub)nomencltor:

1. Nomencltor intrnseco propio: El perteneciente a su trmino municipal.
2. Nomencltor adyacente metropolitano: El que abarca una cierta rea de
influencia del municipio.


3. Nomencltor extrnseco estatal: El qu ser necesario para trmites
municipales en los que no se prev la presencia fsica de ningn servicio
municipal del municipio original.

Efectivamente, las necesidades del municipio para cada una de esas zonas es
bien distinto. Estudiemos cada una de ellas:

NOMENCLATOR INTRINSECO O PROPIO

Es el que dar respuesta al conjunto de eventos acaecidos en el propio trmino
municipal. Sus caractersticas sern:

- Nivel muy alto de detalle.
- Precisa de una rpida actualizacin.
- Necesidad del conocimiento de la historia de cada elemento del nomencltor.
- Elevado mantenimiento de varianteros.
- Evolucin continua de la normalizacin de direcciones.
- Nivel continuo de actualizacin de elementos identificables con las direcciones.
- Cartografa de gran escala (topomtricos, temticos, guas de ciudad y tcnicos)

Es evidente que en el propio trmino municipal se concentra el grueso de las
actividades municipales. La necesidad de informacin es mxima, pues un
desconocimiento, imprecisin o error en los datos trasciende invariablemente a una
prdida en la eficacia municipal. En este caso la gran mayora de actividades y
gestiones que se realizaran sobre una nueva zona de la ciudad sern de carcter
municipal (licencia de obras de edificacin, recepcin de zonas urbanizadas, etc.). En
este momento la informacin alfanumrica del nomencltor debe ya de ser completa,
no obstante en cuanto a cartografa podramos estar en la fase de planos topomtricos
y de carcter tcnico. Ahora bien, en el momento en que una zona de la ciudad se
urbaniza y consolida, no decae la necesidad de actualizacin (no es extrao que en


Madrid se produzcan cada semana un promedio de 100 ocurrencias de renumeracin
y/o cambio de calle en direcciones) y la cartografa debe de estar completada para
cubrir todas las necesidades municipales.

Sabemos que es el propio Ayuntamiento el responsable de su nomencltor y
fundamentalmente de la parte de este correspondiente al callejero. Esta actividad se
realiza a travs del Departamento de Cartografa del rea de Gobierno de Urbanismo y
Vivienda que es quien notifica a las Juntas de Distrito los viales disponibles para la
asignacin de nombre tras la aprobacin de los nuevos planeamientos urbanos (hasta
ese momento se les asigna un nombre provisional, normalmente relativo al propio
planeamiento). A partir de esa notificacin, que se acompaa de un estudio de los
topnimos histricos del lugar, las Juntas proponen los nombres para calles y plazas.
Seguidamente, los expedientes se elevan a la Comisin de Las Artes y, despus, al
Pleno del Ayuntamiento para su aprobacin definitiva, momento en el cual pasa a
formar parte oficial del callejero.

En el caso de la toponimia, esta deber de recoger la informacin suministrada
por la Direccin General de Cooperacin con la Administracin Local de la Consejera
de Presidencia de la Comunidad de Madrid, as como algunos topnimos especficos de
la propia ciudad que por su carcter localizado no son de inters para la toponimia
regional o nacional (esto es una de las caractersticas de la toponimia municipal: El
barrio de Doa Carlota -este no es un barrio oficial-, la Colonia de los Ferroviarios, la
colonia Jess Divino Obrero, Plaza de los cubos, la UVA de Hortaleza o Borondo son
topnimos de la ciudad. Constituyen los casi siempre olvidados topnimos
municipales).

El mantenimiento del nomencltor de la ciudad est directamente relacionado
con la produccin y revisin cartogrfica siendo la una dependiente de la otra en
muchos casos. Ese es el motivo por el que en el Ayuntamiento de Madrid es el
Departamento de Cartografa del rea de Gobierno de Urbanismo y Vivienda quien se
encarga de esa importante tarea, de manera que siempre existe una relacin de
elementos iguales tanto en la parte alfanumrica del nomencltor como en la
cartogrfica. De esta manera no se producen incongruencias, imprecisiones ni errores
en un instante de tiempo t por tratarse de nico gestor de informacin.




Nuevas numeraciones en el municipio de Madrid 1998-2008
Fte rea Urbanismo y Vivienda (Ayuntamiento de Madrid)

El nomencltor intrnseco del Ayuntamiento de Madrid debe sustentarse en un
apoyo geogrfico preciso, sobre el que se plasme la cartografa y sirva de sustento a
operaciones geomtricas a realizar dentro de su trmino. Con este propsito nuestro
municipio tiene una Red Topogrfica propia que debe de conservarse y mantenerse
teniendo en cuenta la continua actividad en la ciudad. La Red Topogrfica municipal
consta de 4.131 vrtices en ETRS89 (European Terrestrial Reference System 1989) de


acuerdo a la red REGENTE y al REAL DECRETO 1071/2007 de 27 de Julio, por el que se
regula el sistema geodsico de referencia oficial en Espaa. Por otra parte el
Ayuntamiento tiene la obligacin otorgada por el REAL DECRETO 1545/2007 de 23 de
noviembre de realizar aquellas escalas cartogrficas superiores a 1:5000, por lo que el
aspecto cartogrfico del nomencltor queda garantizado. El acceso a esta red
topogrfica es un servicio pblico accesible a travs del visualizar urbanstico del
Ayuntamiento de Madrid, a travs del cual se podrn obtener las reseas de todos y
cada uno de los vrtices municipales de la ciudad.

Ejemplo de resea de un vrtice del municipio. Fte: Visualizador Urbanstico municipal

La red se completa adems con una red geotcnica compuesta por 7.125
calicatas, penetrmetros y sondeos y con el mantenimiento del lmite del trmino
municipal (cualquier alteracin del mismo requerir la autorizacin del Consejo de
Gobierno de la Comunidad de Madrid, como por ejemplo el Decreto 67/2006 de 2 de
Agosto, por el que Madrid cedi a Rivas-Vaciamadrid 13,84 Ha).


Este departamento adems colabora con el Proyecto europeo Galileo y con la
Agencia Espacial Europea en estudios concretos, lo que nos da una idea de la gran
preparacin de su personal.

Es evidente que todas estas tareas requerirn de:
- Un equipo humano altamente especializado y con gran experiencia
- Una base de datos fiable, estructurada y contrastada
- Un sistema consolidado de aplicaciones de mantenimiento
- Un plan de actualizacin, mantenimiento y mejora de la informacin

El callejero adems es importante decir que en el caso de Madrid est avalado
por la norma UNE-EN: ISO 9001:2000, lo cual constituye un ndice de calidad externo e
independiente. El protocolo que rene toda la normativa de gestin de callejero es la
norma municipal PNT-CLLM-01.

El rea de Gobierno de Urbanismo y Vivienda se encarga de toda la gestin y
mantenimiento del nomencltor de la ciudad, pero como hemos visto ello no cubre la
totalidad de las necesidades de la misma (an constituyendo la parte esencial del
mismo), de manera que el Ayuntamiento de Madrid tiene un nomencltor centralizado
denominado genricamente Base de Datos Ciudad (BDC) responsabilidad de
Informtica Ayuntamiento de Madrid, del cual se responsabiliza un Analista Ingeniero
Tcnico en Topografa, bajo una Jefatura de Servicio de un Ingeniero en Geodesia y
Cartografa.

El flujo de informacin entre el Departamento de Cartografa del rea de
Gobierno de Urbanismo y Vivienda y la Base de Datos Ciudad de Informtica
Ayuntamiento de Madrid se produce cada 24 horas, de manera que lo gestionado en el
Departamento de Cartografa slo pasa a conformar parte de la Base de Datos Ciudad
si se da por consolidado. La media de movimientos de la ciudad con respecto al


nomencltor intrnseco es de unos 181.000 (para el periodo 2000-2008) en la ciudad
de Madrid. El nmero de calles del municipio es de 9.145 a fecha 18 de diciembre de
2012.

La Base de Datos Ciudad (en adelante BDC) ser el nomencltor aglutinador de
todos los nomencltor al que adems aadir servicios de valor aadido para que
cualquier aplicacin municipal disponga de un nomencltor que ane al nomencltor
intrnseco, adyacente y extrnseco.

NOMENCLATOR ADYACENTE O METROPOLITANO

Es el que dar respuesta al conjunto de eventos acaecidos en la zona de
influencia de la ciudad que se encuentre fuera de los lmites del trmino municipal
propio. Sus caractersticas son:

- Nivel alto de detalle.
- Precisa de forma regular una actualizacin.
- El conocimiento de la historia de sus elementos es menos relevante.
- No es necesario variantero a nivel de callejero.
- La normalizacin de direcciones sigue resultando de inters.
- Slo se requerir informacin de aquellos elementos identificables con
direcciones que guarden relacin con el callejero intrnseco (Ej: red de
transportes)
- La cartografa ya no es imprescindible, aunque si aconsejable. En cualquier caso
las guas de ciudad o urbanas son suficiente ayuda y las escalas pueden ser del
orden de 1:10.000

En Madrid se producen dos fenmenos migratorios de gran trascendencia para
la ciudad, el acaecido en la dcada de 1960 y el ocurrido en la de 1970. La ciudad se vio


incapacitada para absorber la corriente de inmigracin. El Conde de Romanones en
1902 realiza una primera divisin en diez distritos basndose en criterios
demogrficos. En la dcada de los 1940-1950 algunos municipios perifricos absorben
gran cantidad de poblacin y se unen de facto a Madrid. As en 1955 y a raz de la
anexin de municipios limtrofes desde 1948 a 1954 (Aravaca, Barajas, Canillas,
Canillejas, Carabanchel alto y bajo, Chamartn de la Rosa, Fuencarral, Hortaleza, El
Pardo, Vallecas, Viclvaro y Villaverde) se crea una estructura de 18 distritos (Despus
ha habido nuevas divisiones 1970 (18 distritos) y la ltima de 1988 con 21 distritos).

A partir de 1955 el flujo migratorio persiste. Ya no se piensa en anexionar
nuevos municipios a Madrid, que sufre graves problemas de servicios en la ciudad. En
ese momento la corona metropolitana experimenta un aumento demogrfico enorme
que a veces resulta en conurbanizacin (proceso por el que dos poblaciones se unen
en su expansin). Se habla de las ciudades dormitorio. En los 60 Mostoles duplico su
poblacin de principios de siglo, Alcal de Henares duplica su poblacin entre 1960 y
1975 y municipios como Villalba no paran de crecer. Hemos de decir que en la franja
1940-1960 Madrid haba duplicado prcticamente su poblacin. La expansin de los
municipios limtrofes hizo que el Estado se preocupase por la situacin creando la
COPLACO (Comisin de Planeamiento del rea Metropolitana de Madrid) en 1963 y
cuyas funciones se transfirieron a la Comunidad de Madrid con su creacin. Segn el
autor Teran Troyano hemos de tener en cuenta que el 60% de las casas de Madrid
haban sido construidas terminada la guerra civil y era necesario crear una ordenacin
urbanstica que consider a Madrid y a 23 trminos municipales aledaos.

Si para cada municipio cercano a Madrid se tiene en cuenta el volumen,
densidad de poblacin, peso econmico por afiliados a la S.Social y su relacin con la
poblacin (Hay 35 municipios en los que ms del 50% de su poblacin afiliada trabaja
fuera de dicho municipio), grado de ocupacin urbanstica y curvas iscronas de
tiempos de trayecto hasta la ciudad de Madrid y dichas variables se ponderan en
funcin de la frmula (valor real-valor mnimo)/(valor mximo valor mnimo),
obtenemos un ndice sinttico que segn el observatorio econmico de Madrid arroja
cuatro coronas metropolitanas que nos dan una idea de la gran influencia y relacin de
la ciudad con los municipios colindantes:



- rea Urbana Metropolitana
- rea Suburbana Metropolitana
- rea de expansin periurbana
- rea de difusin periurbana

Las reas metropolitanas presentan una jerarqua basada en este caso en la
ciudad de Madrid, que crea una dependencia para municipios adyacentes y en el que
se dan los tpicos flujos residencia-trabajo. En el caso de Madrid, el rea metropolitana
supera los lmites administrativos de la Regin, lo que ocasiona un problema a la hora
del mantenimiento de un nomencltor al ser varias las Comunidades Autnomas
encargadas de centralizar los callejeros de sus respectivas poblaciones. En el caso de
Madrid, las provincias de vila, Guadalajara y Toledo tienen una gran dependencia
hasta tal punto que el Consorcio Regional de Transportes de Madrid ha firmado
acuerdos con las Comunidades limtrofes para estar incluidas en el rea de transportes
de nuestra provincia. El lmite de influencia est entre 40-80 Km para Madrid. An lejos
de los 100 Km de otras grandes ciudades europeas.

Evolucin comparativa de la poblacin de las reas metropolitanas de Madrid y Barcelona. Fte: INE



reas metropolitanas y ciudades satlites de Madrid (ver imagen previa tambin)
Fuente .- Barmetro de Economa de la Ciudad de Madrid



Vemos pues la gran importancia que para el Ayuntamiento de Madrid tiene el
conocimiento de los territorios sobre los que influye. Por ello y porque dicha rea no
para de crecer demogrficamente representa fundamental el poder disponer de
manera regular de un nomencltor de dicha rea de influencia.

Pensemos en la gran interaccin que genera este flujo, tanto en la incidencia de
los propios autobuses urbanos, como en la incidencia del trfico, como en el conjunto
de servicios que el municipio debe de poner a disposicin no slo para sus propios
ciudadanos, sino tambin para el flujo diario que le llega.

Por otro lado los servicios de emergencia pueden en algunos casos tener la
necesidad de superar sus lmites lo que obliga a un conocimiento completo de dicha
rea de influencia.

Adems se generan trmites administrativos derivados como pueden ser
atestados, multas de circulacin y trmites de toda ndole (consultas, tributos,
reclamaciones) que tendrn como punto comn el conocimiento de al menos una
direccin (la del domicilio del ciudadano que en orden a criterios puramente
estadsticos tiene altas posibilidades de pertenecer a dicha rea).

Para la Base de Datos Ciudad (BDC) del Ayuntamiento el nomencltor
adyacente lo han ido componiendo sucesivamente municipios cercanos a la ciudad (el
llamado ALFOZ). En la actualidad el ALFOZ de Madrid de cara al nomencltor lo
constituye toda la Regin de Madrid con la prctica totalidad de sus municipios. El
Instituto de Estadstica de la Comunidad proporciona al cierre de callejeros de la
Regin dicha informacin. La cartografa usada en este caso se realiza a travs de
NOMECALLES de la CAM, personalizando para el municipio en cuestin la cartografa
urbana, disponiendo de un nomencltor de gran calidad de cara a las necesidades
municipales con 36.887 calles y sus respectivas numeraciones actualizadas. Vemoslas
en detalle:



POBLACIONES ALFOZ CALLES POBLACIONES ALFOZ CALLES
ACEBEDA (LA) 16 MORATA DE TAJUA 207
AJALVIR 113 MOSTOLES 523
ALAMEDA DEL VALLE 33 NAVACERRADA 106
ALAMO (EL) 220 NAVALAFUENTE 84
ALCALA DE HENARES 1111 NAVALAGAMELLA 117
ALCOBENDAS 395 NAVALCARNERO 330
ALCORCON 536 NAVARREDONDA 48
ALDEA DEL FRESNO 136 NAVAS DEL REY 190
ALGETE 226 NUEVO BAZTAN 120
ALPEDRETE 302 OLMEDA DE LAS FUENTES 39
AMBITE 90 ORUSCO 93
ANCHUELO 67 PARACUELLOS DE JARAMA 324
ARANJUEZ 509 PARLA 425
ARGANDA DEL REY 615 PATONES 44
ARROYOMOLINOS 276 PEDREZUELA 159
ATAZAR (EL) 25 PELAYOS DE LA PRESA 181
BATRES 71 PERALES DE TAJUA 89
BECERRIL DE LA SIERRA 275 PEZUELA DE LAS TORRES 69
BELMONTE DE TAJO 81 PINILLA DEL VALLE 34
BERRUECO (EL) 68 PINTO 424
BERZOSA DEL LOZOYA 58 PIUECAR 71
BOADILLA DEL MONTE 424 POZUELO DE ALARCON 816
BOALO (EL) 345 POZUELO DEL REY 59
BRAOJOS 33 PRADENA DEL RINCON 24
BREA DE TAJO 106 PUEBLA DE LA SIERRA 30
BRUNETE 190 PUENTES VIEJAS 122
BUITRAGO DEL LOZOYA 104 QUIJORNA 150
BUSTARVIEJO 139 RASCAFRIA 110
CABANILLAS DE LA SIERRA 63 REDUEA 21
CABRERA (LA) 158 RIBATEJADA 71
CADALSO DE LOS VIDRIOS 184 RIVAS-VACIAMADRID 535
CAMARMA DE ESTERUELAS 171 ROBLEDILLO DE LA JARA 35
CAMPO REAL 168 ROBLEDO DE CHAVELA 291
CANENCIA 40 ROBREGORDO 31
CARABAA 148 ROZAS DE MADRID (LAS) 880
CASARRUBUELOS 108 ROZAS DE PUERTO REAL 65
CENICIENTOS 121 SAN AGUSTIN DE GUADALIX 148
CERCEDILLA 283 SAN FERNANDO DE HENARES 257
CERVERA DE BUITRAGO 28 SAN LORENZO DE EL ESCORIAL 286
CHAPINERIA 133 SAN MARTIN DE LA VEGA 286


CHINCHON 196 SAN MARTIN DE VALDEIGLESIAS 353
CIEMPOZUELOS 278 SAN SEBASTIAN DE LOS REYES 541
COBEA 128 SANTA MARIA DE LA ALAMEDA 277
COLLADO VILLALBA 433 SANTORCAZ 79
COLLADO-MEDIANO 222 SANTOS DE LA HUMOSA (LOS) 107
COLMENAR DE OREJA 329 SERNA DEL MONTE (LA) 33
COLMENAR DEL ARROYO 117 SERRANILLOS DEL VALLE 109
COLMENAR VIEJO 645 SEVILLA LA NUEVA 135
COLMENAREJO 195 SOMOSIERRA 19
CORPA 40 SOTO DEL REAL 319
COSLADA 339 TALAMANCA DE JARAMA 121
CUBAS DE LA SAGRA 151 TIELMES 126
DAGANZO DE ARRIBA 132 TITULCIA 72
ESCORIAL (EL) 336 TORREJON DE ARDOZ 487
ESTREMERA 138 TORREJON DE LA CALZADA 120
FRESNEDILLAS DE LA OLIVA 128 TORREJON DE VELASCO 146
FRESNO DE TOROTE 93 TORRELAGUNA 194
FUENLABRADA 680 TORRELODONES 351
FUENTE EL SAZ DE JARAMA 137 TORREMOCHA DE JARAMA 83
FUENTIDUEA DE TAJO 101 TORRES DE LA ALAMEDA 191
GALAPAGAR 718 TRES CANTOS 368
GARGANTA DE LOS MONTES 105 VALDARACETE 52
GARGANTILLA DEL LOZOYA 89 VALDEAVERO 85
GASCONES 35 VALDELAGUNA 74
GETAFE 1204 VALDEMANCO 68
GRION 282 VALDEMAQUEDA 91
GUADALIX DE LA SIERRA 164 VALDEMORILLO 472
GUADARRAMA 347 VALDEMORO 465
HIRUELA (LA) 14 VALDEOLMOS 115
HORCAJO DE LA SIERRA 51 VALDEPIELAGOS 45
HORCAJUELO DE LA SIERRA 35 VALDETORRES DE JARAMA 136
HOYO DE MANZANARES 181 VALDILECHA 85
HUMANES DE MADRID 267 VALVERDE DE ALCALA 43
LEGANES 824 VELILLA DE SAN ANTONIO 157
LOECHES 178 VELLON (EL) 109
LOZOYA 73 VENTURADA 136
LOZOYUELA-NAVAS-
SIETEIGLESIAS 127 VILLA DEL PRADO 275
MADARCOS 23 VILLACONEJOS 89
MAJADAHONDA 515 VILLALBILLA 358
MANZANARES EL REAL 253 VILLAMANRIQUE DE TAJO 80
MECO 228 VILLAMANTA 98


MEJORADA DEL CAMPO 213 VILLAMANTILLA 88
MIRAFLORES DE LA SIERRA 329 VILLANUEVA DE LA CAADA 289
MOLAR (EL) 213 VILLANUEVA DE PERALES 75
MOLINOS (LOS) 213 VILLANUEVA DEL PARDILLO 229
MONTEJO DE LA SIERRA 65 VILLAR DEL OLMO 56
MORALEJA DE ENMEDIO 153 VILLAREJO DE SALVANES 204
MORALZARZAL 284 VILLAVICIOSA DE ODON 419

VILLAVIEJA DEL LOZOYA 60

ZARZALEJO 139

NOMENCLATOR EXTRINSECO O ESTATAL

Obviamente a medida que las localizaciones con las que el Ayuntamiento de
Madrid tiene que interactuar se alejan de su territorio, tambin decrece la necesidad
de convivencia con las mismas, por lo que su importancia estadstica con respecto a
aciertos en el sistema de nomencltor tambin pierde peso.

Es indiscutible que son los ciudadanos los que se relacionan con el municipio y a
ellos nos debemos, de manera que se debe de dar en este nomencltor un equilibrio
entre:

- Calidad del nomencltor estatal
- Disponibilidad de la informacin
- Homogeneidad de la informacin.
- Facilidad y temporalidad de las actualizaciones.
- Practicidad final de la informacin.

A 1 de enero de 2011, segn el I.N.E. y de acuerdo a los datos padronales
proporcionados por cada una de las capitales de provincia (50 incluyendo Madrid),
estas tenan una poblacin total de 11.799.495 personas (exceptuando Madrid capital)
de un total de 40.700.813 (exceptuando Madrid provincia). La relacin de proporcin
de ciudadanos que viven en las capitales de provincia es del 29% y adems muchas de
las relaciones se establecen a travs de personas jurdicas que suelen tener su sede en


las mismas. Ello quiere decir que el porcentaje real de datos que sern usados
mayoritariamente es muy superior, no obstante para una menor incidencia en la
correcta localizacin de datos, en el Ayuntamiento de Madrid se incluyen los callejeros
de otras poblaciones que tienen ms de un cdigo postal. Esto arroja un total de
103.041 calles de poblaciones de fuera de la Comunidad Autnoma de Madrid.
Veamos cuales:

PROVINCIA POBLACIN CALLES
A CORUA CORUA, A 1351
A CORUA FERROL 591
A CORUA SANTIAGO DE COMPOSTELA 836
ALAVA-ARABA VITORIA-GASTEIZ 890
ALBACETE ALBACETE 726
ALICANTE-ALACANT ALCOI/ALCOY 433
ALICANTE-ALACANT ALICANTE/ALACANT 1648
ALICANTE-ALACANT BENIDORM 468
ALICANTE-ALACANT ELX/ELCHE 1025
ALICANTE-ALACANT TORREVIEJA 1223
ALMERIA ALMERIA 2106
ASTURIAS AVILES 563
ASTURIAS GIJON 1347
ASTURIAS OVIEDO 856
AVILA AVILA 658
BADAJOZ BADAJOZ 1210
BARCELONA BADALONA 873
BARCELONA BARCELONA 4665
BARCELONA GRANOLLERS 451
BARCELONA HOSPITALET DE LLOBREGAT, L 536
BARCELONA MANRESA 594
BARCELONA MATARO 869
BARCELONA SABADELL 1299
BARCELONA SANT CUGAT DEL VALLES 1078
BARCELONA SANTA COLOMA DE GRAMENET 305
BARCELONA TERRASSA 1264
BURGOS BURGOS 1015
CACERES CACERES 1025
CADIZ ALGECIRAS 1124
CADIZ CADIZ 804
CADIZ JEREZ DE LA FRONTERA 2170


CANTABRIA SANTANDER 722
CASTELLON-CASTELLO CASTELLON/CASTELLO 1340
CEUTA CEUTA 563
CIUDAD REAL CIUDAD REAL 567
CORDOBA CORDOBA 2047
CUENCA CUENCA 393
GIRONA GIRONA 877
GRANADA GRANADA 2365
GUADALAJARA GUADALAJARA 619
GUIPUZCOA-GIPUZKOA DONOSTIA-SAN SEBASTIAN 801
GUIPUZCOA-GIPUZKOA IRUN 378
HUELVA HUELVA 1004
HUESCA HUESCA 386
ILLES BALEARS MAO 258
ILLES BALEARS PALMA DE MALLORCA 2612
JAEN JAEN 940
LA RIOJA LOGROO 636
LAS PALMAS PALMAS DE GRAN CANARIA, LA 2961
LAS PALMAS TELDE 1279
LEON LEON 1465
LEON PONFERRADA 614
LLEIDA LLEIDA 1027
LUGO LUGO 691
MALAGA MALAGA 4888
MALAGA MARBELLA 2236
MALAGA MIJAS 1135
MELILLA MELILLA 908
MURCIA CARTAGENA 1666
MURCIA MOLINA DE SEGURA 1184
MURCIA MURCIA 2294
NAVARRA PAMPLONA/IRUA 1209
OURENSE OURENSE 911
PALENCIA PALENCIA 589
PONTEVEDRA PONTEVEDRA 633
PONTEVEDRA VIGO 1567
SALAMANCA SALAMANCA 1629
SANTA CRUZ DE
TENERIFE SAN CRISTOBAL DE LA LAGUNA 1443
SANTA CRUZ DE
TENERIFE SANTA CRUZ DE TENERIFE 1268
SEGOVIA SEGOVIA 588
SEVILLA DOS HERMANAS 1311


SEVILLA SEVILLA 4495
SORIA SORIA 438
TARRAGONA REUS 981
TARRAGONA TARRAGONA 775
TERUEL TERUEL 409
TOLEDO TOLEDO 961
VALENCIA GANDIA 677
VALENCIA VALENCIA 3508
VALLADOLID VALLADOLID 1736
VIZCAYA-BIZKAIA BARAKALDO 343
VIZCAYA-BIZKAIA BILBAO 1180
VIZCAYA-BIZKAIA GETXO 334
ZAMORA ZAMORA 766
ZARAGOZA ZARAGOZA 2431

Hay que tener en cuenta que en el nomencltor extrnseco la
georreferenciacin cartogrfica ya no es necesaria para el municipio (an cuando
correos dispone de gran parte de ella), de modo que la direccin del nomenclator ser
fiable en definitiva si somos capaces de que el Ayuntamiento pueda relacionarse con el
ciudadano y as hasta la numeracin a nuestros efectos deja de ser esencial, ya que lo
realmente importante es que la tramificacin de calles de acuerdo al sistema postal
con respecto a las numeraciones sea correcta. Lo ms efectivo en este caso es contar
con los servicios postales. En el caso del Ayuntamiento de Madrid, existe un acuerdo
con Correos y Telgrafos.

El INE como receptor de movimientos padronales dispone del concepto de
pseudova y otros que constituyen particularidades de un sistema de actualizacin
basado en el CENSO con lo que no se adapta totalmente a las caractersticas del
callejero real de la ciudad. El propio carcter de este callejero, pese a ser oficial hace
que determinadas zonas no existan (pensemos en polgonos industriales, carreteras y
aunque no sea el caso de Madrid en otras zonas calles completas destinadas a
viviendas vacacionales). Todo lo anterior junto a la necesidad de minimizar el rechazo
en envos postales que optimicen los recursos hacen que la mejor decisin sea la de
recibir la informacin del proveedor de cdigos postales.



Un defecto que tradicionalmente le achacabamos al callejero de correos era el
de no relacionar las poblaciones con los municipios, tarea que desde la segunda mitad
de la dcada de 2000 se viene corrigiendo progresivamente existiendo en la actualidad
una ligazn creciente con los datos INE de municipios a travs de su cdigo.

Podemos decir tambin que una posibilidad aadida fuese el callejero de
Catastro y es cierto, pero el volumen de informacin con respecto a los beneficios
obtenidos lo desaconseja. En este caso la componente espacial no es necesaria y s que
lo es la codificacin postal. Tal vez resultase interesante complementar en su caso la
informacin de calles de aquellas poblaciones de codificacin postal nica. Ello
provocara un callejero completo de Espaa, pero que dudosamente resultara
rentable para el municipio. No podemos olvidar adems que en Catastro encontramos
vas muy desactualizadas, vas sin nombre y vas duplicadas. El nivel de actualizacin se
presupone menor en poblaciones menores, que es precisamente las que no
tendramos solucionadas, con lo cual aadimos un pero ms al uso de este callejero
como complemento eficaz al de Correos para el caso de nuestro nomencltor
extrnseco.
Se trata pues en este caso, no de manejar un histrico total o parcial de las
relaciones (como era el caso de la ciudad y de los municipios de la Comunidad), sino
que en un momento dado (instante T inicial de relacin con el ciudadano), la direccin
introducida sea correcta y llegue. Estaremos pues ante un nomencltor bsico que
permite aglutinar las cinco especificaciones que requerimos y que hemos visto ms
arriba.

Debemos destacar el gran esfuerzo que Correos viene realizando por
constituirse como un proveedor de informacin de empresas y administraciones.
Pongamos por ejemplo las relaciones con la cartografa de Canarias (GRAFCAN), que
desde el ao 2004 viene encargando a Correos la revisin de callejeros de poblaciones
como Santa Cruz de Tenerife, La Oratava, El Tanque y muchos ms. Otro ejemplo es el
acuerdo de correos con la diputacin de Mlaga para la realizacin del callejero
provincial a travs de WMS bajo plataforma MapServer.

Adems Correos tiene un potencial aadido para las ciudades que es el gran
nmero de carteros que recorren las vas de una ciudad y que a travs de contratos


concretos pueden ser de gran ayuda a incidencias en la ciudad. Tengamos en cuenta
que hoy en da los carteros disponen de libretas electrnicas, cuyas descargas al
finalizar su jornada laboral podran representar un listado de incidencias
georreferenciadas de gran utilidad para el mantenimiento de una ciudad.

LA NECESIDAD DE UN MODELO AUTNOMO

Hemos visto en los apartados anteriores la complejidad tipolgica de un
nomencltor de una gran urbe. Efectivamente la optimizacin de recursos, la
necesidad de mantenimiento y la dificultad en una transferencia gil de informacin
hacen necesaria la subdivisin del nomencltor, segn las necesidades del
Ayuntamiento.

En esencia, y as se hace en muchos municipios, slo se dispone del propio
nomencltor, no obstante la complejidad de una ciudad cuya poblacin a enero de
2011 representa el 50,33% de la provincia y queda rodeada por una poblacin de
3.224.642 habitantes es bien distinta y precisa de un nomencltor con un grado de
sofisticacin muy elevado.

Ninguno de los callejeros que podran considerarse para el Consistorio de
Madrid reflejan la historia del callejero, lo cual desde el punto de vista municipal
representa ya de por si un obstculo enorme. Pongamos un ejemplo: Supongamos que
inicio con el Ayuntamiento de Madrid un trmite administrativo. En un momento dado
esa direccin (ejemplo: Avda Isabel de Valois 43B) se renumera o cambia de calle. Ante
este panorama y sin disponer de historia un posible escenario podra ser:

1. Las respuestas se tramitan a la direccin inicial. Devolucin posible tarde o
temprano. (Factor suerte?, Factor pericia del cartero?, Hay suerte y no hay
cambio en el cdigo postal o la seccin de cartera?)
2. El ciudadano comunica que no se le responde


3. El Ayuntamiento le comunica que la direccin que facilit es incorrecta
4. El ciudadano responde diciendo que han recibido en la comunidad de vecinos
la comunicacin del cambio.
5. El servicio municipal correspondiente se pone en contacto con los servicios
cartogrficos quien le comunican la veracidad del cambio
6. Se inicia el trmite de respuesta

El escenario es descorazonador, ineficaz administrativa y econmicamente,
proporciona al ciudadano una imagen negativa y adems sus consecuencias pueden
resultar injustas para el ciudadano o para el Ayuntamiento.

Cul sera la respuesta de callejeros basados en nomencltores de instante T
para este supuesto?. Veamos:

- CATASTRO: ERROR Cdigo 43 El nmero no existe. Catastro a travs del Web
Service.
- NOMECALLES C.A.M.: La numeracin no nos aparece y no la podemos
seleccionar.
- GOOGLEMAPS: No nos dice nada. Nos manda 0.54 Km. calle abajo.
- CARTOCIUDAD: La numeracin no nos aparece y nos obliga a seleccionar un
nico nmero el 82?

Sin embargo la respuesta municipal debera de identificar el cambio en la
direccin y automatizar el cambio poniendo la direccin correcta. Por ello es necesario
un nomencltor intrnseco, porque en su definicin est el concepto de historia y en
Madrid se producen muchsimas modificaciones por ser una gran ciudad.

La respuesta en el caso del Ayuntamiento de Madrid sera la correcta: Si el
trmite se dio de alta con la direccin anterior y luego sta ha cambiado, desde ese
momento la nueva direccin ser C/ Mara Tudor 12D, pudiendo obtener la anterior,
sin ms que poner la fecha de inicio de trmite, lo cual es fundamental para el
concepto de callejero propio o intrnseco.



GoogleMaps nos enva medio kilmetro calle abajo. El peor de los casos posibles.

Nomecalles no nos permite seleccionar.

Cartociudad no nos permite seleccionar y adems nos da muy poca informacin.


Efectivamente en la situacin morada no podremos llegar al ciudadano a travs
de la direccin B (entrada en el sistema por direccin para localizar elementos
asociados a la misma). Al mismo tiempo el ciudadano ya no est realmente
relacionado con A, luego si nuestro sistema obvia esa situacin tendremos problemas
de comunicacin e identificacin de dicho ciudadano. En realidad la situacin
geomtrica del domicilio A y B no ha variado, slo su direccin literal ha cambiado de
nombre. Un nomencltor municipal debe de recoger esta circunstancia.

Es obvio por tanto que para el caso del nomencltor intrnseco o propio, no
existe una solucin adecuada para su incorporacin en la Base de Datos Ciudad del

Por otro lado la calidad de la informacin de la Comunidad Autnoma para el
resto de los municipios de la regin ha mejorado con el paso del tiempo y en la
actualidad se puede recibir una y en ocasiones dos actualizaciones al ao, que se
corresponden con los cierres de los callejeros de toda la provincia. Esto unido a la
posibilidad de generar historia, de disponer de georreferenciacin de las direcciones y
poner a disposicin de los municipios un sistema de visualizacin centralizado


(nomecalles), lo hacen la herramienta ideal para el nomencltor adyacente o
metropolitano.

Antes de continuar, debemos decir que el Ayuntamiento de Madrid es el
proveedor de informacin del resto de nomencltores del Estado. Luego directa o
indirectamente la informacin que todo Organismo Pblico est cargando en su
sistema, salvo error u omisin de los procesos intermedios es la informacin disponible
del municipio a la fecha de envo y que procede del propio Ayuntamiento de Madrid.

Ahora bien, para las necesidades del nomencltor extrnseco o estatal resulta
curioso que no haya una herramienta nica en la segunda dcada del S. XXI. Veamos
sucintamente algunas de las distintas posibles fuentes:

- Nomenclator geogrfico nacional y nomencltor bsico de Espaa y
nomencltor conciso de Espaa (I.G.N.): Est enfocado a la generacin
cartogrfica 1:25.000 y en ella no se contemplan callejeros, como corresponde
a dicha escala. Es muy til para otros usos, pero no para un nomencltor
municipal.
- Cartociudad (I.G.N.): Se trata de un proyecto de gran proyeccin. Uno de sus
problemas es que se inici en el ao 2006 (El Ayuntamiento de Madrid antes
del inicio del proyecto tena que tener una solucin al problema del
nomencltor estatal). Otro problema es que no ofrece garantas totales de
continuidad y mantenimiento concreto. En su pgina web se especifica: Las
lneas de trabajo a corto y medio plazo implican el mantenimiento y la
actualizacin continua de los datos en colaboracin con los gobiernos de las
comunidades autnomas siempre que sea posible. Siempre que sea posible?
!!!. A favor del proyecto decir que el I.G.N. parece decidido a su
consolidacin, no obstante en su contra diremos que siendo el enfoque de
carcter provincial y local no se hayan considerado las necesidades de los
grandes Ayuntamientos (al menos desde Base de Datos Ciudad del
Ayuntamiento de Madrid no tenemos constancia), lo cual es muy grave, pues es
difcil dar soluciones reales sobre una base de conocimiento de la necesidad
excesivamente abstracto. Destacar los esfuerzos por difundir su uso,
fundamentalmente de georreferenciacin pero se echan en falta otras
herramientas que a la AALL nos seran de mayor utilidad.


(http://www.cartociudad.es/VisualizadorCartografico/). El Api est basado slo
en jsp y no se proporcionan API para otro tipo de usos ms personalizados.
- Callespaa es un callejero para referencia, estadstico y postal de Espaa con
geoposicionamiento parcial desarrollado por Carlos Javier Martn Gonzlez. Se
trata de un excelente trabajo personal basado en los datos del I.N.E. muy
depurados y tamizados por poblacin y cdigo postal por la aplicacin
geonames para obtener una georreferenciacin de poblacin. Se trata de un
proyecto que no ofrece garantas de continuidad que se vende empaquetado
listo para poder utilizar, pero que incluye muchas utilidades bsicas que para
un nomencltor estatal o extrnseco demanda un municipio como el nuestro.
Decir, eso s, que soluciona unas 300.000 direcciones a la hora, lo que resulta
insuficiente para Ayuntamientos como Madrid (Necesidades del 1200% mayor
que esa cifra de proceso). Pueden verse ejemplos de su funcionamiento en:
(http://callespana-demos.com.es:8082/CspanaCALLEJERO/index.jsp). Se ha
puesto como ejemplo de las distintas soluciones privadas que existen. Es un
ejemplo de cmo el mundo de la empresa privada GD Geographic Data
Management Ltd. (GDM), Atlas, Navstar etc. se hace eco de una necesidad que
debera de resolver en algunos casos la propia Administracin y que genera
elevados volumenes de negocio.
- EIEL es un proyecto del Ministerio de Hacienda y AAPP que cada cinco aos a
travs de las Diputaciones recibe informacin varia de los municipios menores
de 50.000 habitantes (en el futuro se prev de todos). Entre estas
informaciones estn las calles y sus ejes. En la actualidad (fase 2012) se ataca el
proyecto GEOEIFEL. An es insuficiente aunque puede ser til a medio plazo.
Adems el Ministerio a travs del programa APORTA centraliza informacin de
reutilizacin de inters para las AAPP. El que la actualizacin se realice cada
lustro no es un punto especialmente positivo del proyecto.
- INE. Almacena la informacin de callejeros a travs de la informacin censal. Se
trata de una iniciativa que convenientemente depurada puedes servir a los
efectos de un correcto nomencltor estatal ya que incluye las codificaciones
postales. La descarga se puede realizar a travs de
(http://www.ine.es/ss/Satellite?L=0&c=Page&cid=1254735624326&p=1254735
624326&pagename=ProductosYServicios/PYSLayout). Sus defectos ya fueron
enunciados y nos remitimos a ellos (falta de informacin debido a su carcter
censal y tratamiento complejo de psudovias).
- Servicios de Catastro. El catastro posibilita una herramienta que realmente
tecnolgicamente correcta de tratamiento de callejeros a travs de web
services invocables mediante SOAP a travs de protocolo http GET/POST. El


sistema responde bastante bien, pero el tratamiento de los calificadores es
inadecuado y la codificacin postal no es recibida en la respuesta, lo cual es
fundamental para un Ayuntamiento. Servicios web disponibles son
(https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCallejero.
asmx)
- Apis de empresas de tecnologa web. Google con su googlemaps, Bing con su
bingmaps y yahoo con su yahoomaps son los tres grandes exponentes de este
tipo de tecnologa. Su ventaja es que disponen de api simple que no siempre se
corresponden con el tipo de datos de entrada y distribucin de los mismos a la
entrada. Este tipo de servicios se basan en PLN (NLP en ingls) (procesamiento
natural del lenguaje.) usando http://nlp.stanford.edu ,
http://opennlp.apache.org/ u otros productos con los que obtienen resultados
tiles para un pblico general o de empresa pequea/media, pero que estn
lejos de cubrir las necesidades de un municipio como Madrid.
- Sociedad estatal de Correos y Telgrafos. Actualmente no cubre en cuanto a
callejeros el territorio nacional, pero si aquellas localidades con ms de una
codificacin postal, lo que resulta sumamente prctico a efectos de un
Ayuntamiento. El servicio es de pago y se debe de tratar para integrar en una
BBDD propia. No estn disponibles Api de acceso a la informacin. La
georreferenciacion sabemos que se est llevando a cabo pero desde nuestra
perspectiva de municipio no tiene gran inters.

La ventaja que tienen algunos de los proyectos en marcha es que tienen en
cuenta las directrices europeas de interoperabilidad de OGC
(www.opengeospatial.org/) segn los estndares de la directiva INSPIRE (los realizados
por M de Fomento y M de Hacienda y AAPP). Ya hemos dicho que algunos de estos
proyectos debern de ser contemplados y reanalizados en el futuro, debido a las
buenas perspectivas que ofrecen, siempre y cuando se consoliden como estndares
reales y tengan un mantenimiento adecuado.

Todos los profesionales que trabajamos con nomencltores geogrficos
sentimos la necesidad de un nomencltor extrnseco a nivel nacional, que cubra
cartogrficamente el territorio completo y disponga de los servicios adecuados para el
uso no slo cartogrfico del mismo a travs de servicios de IDEE, sino otros servicios
que puedan ser utilizados en las distintas plataformas y cubran el espectro de usuarios


que ms demandamos este tipo de aplicativos a travs de web services partiendo de
un modelo similar al que usa catastro.

A lo largo de lo expuesto hemos ido viendo, no slo las carencias o problemas
de los distintos servicios nacionales de nomencltor, sino tambin que los niveles de
informacin que una gran AALL requiere son complejos. As pues no hay ninguna
solucin a nivel estatal que cubra las necesidades globales de orden 2 y 3 del
nomencltor (la 1 o intrnseca, queda evidente que es inabordable en un proyecto de
carcter nacional). Creemos que algn da se podr lograr una densificacin nacional
de nomencltor de orden 2 sin ms que lograr sumar las sinergias de las CCAA, el M
de Fomento, el M de Hacienda y AAPP, otros organismos estatales como correos y el
INE. Ello provocara un beneficio econmico pblico y privado notable no slo por el
hecho de disponer de una informacin veraz, sino que el propio hecho de la
centralizacin provocara un notable ahorro en recursos y distribucin.

Hoy por hoy un gran municipio como Madrid necesita pues de un nomencltor
propio en el que se reflejen de manera clara y precisa todas sus necesidades y que
pueda prestar servicio a todas las aplicaciones y dependencias municipales mediante
una operativa eficaz que muestre la realidad tal y como es.

Es por ello que a fecha de hoy al municipio de Madrid no le queda ms remedio
que tener su propio nomencltor, un nomencltor autnomo necesario para una
correcta gestin del Ayuntamiento y sus servicios, que es obligacin prioritaria que
debe de cumplir nuestro Consistorio.



Proyeccin del proyecto CARTOCIUDAD I.G.N. Fte.- Ministerio de Fomento

VENTAJAS E INCONVENIENTES DEL MODELO
AUTNOMO

En el apartado anterior se ha estudiado bastante pormenorizadamente las
posibilidades que nos ofrecan los distintos nomencltores disponibles en Espaa.

Tambin ha quedado clara la necesidad de un modelo autnomo para el caso
de grandes AALL en lo que respecta al nomencltor propio, pero ello no quiere decir
que el modelo autnomo sea el mejor, ni que el camino a recorrer deba de ir en otro
sentido. Toda decisin tiene elementos positivos y negativos que intentaremos aclarar.
Lo haremos dirimiendo estas ventajas e inconvenientes para el caso del nomencltor
2 y el 3, es decir los correspondientes a los nomencltores metropolitanos y
estatales, dejando de un lado a los propios.


Para que el nomencltor de un ayuntamiento como el de Madrid pueda tomar
la decisin parcial de contemplar el uso de un nomencltor centralizado de carcter
estatal se han de dar una serie de caractersticas bsicas:

- Calidad de los datos.
- Actualizacin frecuente.
- Usabilidad real acorde con necesidades.
- Equipo tcnico y Organismo de garanta.
- Capacidad de procesamiento en diferido
- Sistema de informacin y gestor de datos confiable
- Servidores acordes con la demanda.
- Disponibilidad 24 horas.

Es complicado que desde la AALL logremos esto de la central en un corto
periodo de tiempo. Sus sistemas en general se orientan hacia el estudio de datos, pero
no a su utilizacin continua de un nomencltor como sistema de informacin de
ubicaciones.

Vamos a establecer una relacin de ventajas y desventajas que nos dara un
sistema que se comprometiese a lo anterior.

VENTAJAS

1. Un ajuste en el gasto realmente importante. Las crisis econmicas tambin
pueden ser la oportunidad de muchos grandes proyectos.
2. Una clarificacin real de la situacin de los nomencltores. Asumiendo el
Organismo distribuidor una gran responsabilidad de cara al servicio directo al
ciudadano.
3. Generar un ambiente cooperativo entre la Administracin central y las
Comunidades Autnomas clarificando con concrecin las funciones de cada


cual en funcin de sus atribuciones pero tambin en funcin de la solucin
idnea para la resolucin global del problema que abarca todo el Reino.
4. Crear una coleccin de servicios web de un alcance extraordinario que dara
lugar a un S.I. realmente potente. Con seguridad ello dara lugar a
oportunidades de exportacin de conocimiento y tecnologa. Se combinara la
optimizacin de costes con el ingreso de divisas o intercambio tecnolgico.
5. Una seguridad tcnica de cara a la calidad de la geoinformacin y su correcto
procesamiento geomtico.
6. Curvas de aprendizaje del personal encargado de la explotacin del sistema
muy inferior a las actuales. Dicho personal, tendra mayor valor aadido de cara
al mercado laboral.
7. Potenciara la imagen de la importancia de los nomencltores dentro de la
estrategia de desarrollo de cualquier pas. Hoy en da bastante oscura al estar
compuesta por equipos pequeos y disgregados.
8. Generara una plataforma ejemplo para otros servicios que pudiesen
centralizarse y una gran experiencia enriquecedora para todos los ingenieros y
especialistas del rea.
9. Conseguir desatomizar las iniciativas de Diputaciones, Comunidades
Autnomas sin duda bienintencionadas ante la ausencia de informacin til. Se
lograra un efecto desmotivador de desarrollos paralelos. Fundamentalmente si
va acompaado de recomendacin, normativa o decreto que lo avale.

DESVENTAJAS

- Compleja readaptacin de los actuales nomencltores al nuevo diseo, sin
interferir en su forma de uso actual (transparencia para el usuario final
desarrollador).
- Necesaria interrupcin del servicio tanto en servicios web como aplicativos
directos de usuario, como en aquellos que utilicen libreras jsp o similares.
Lentitud o negativa de desarrollo de utilidades que al dueo del nomencltor le
resulten innecesarias o poco generales, lo que representara el desarrollo de
subsistemas locales del nomencltor genrico, lo cual no es en absoluto
recomendable.


- Desconfianza. Teniendo en cuenta que un sistema como el que se propone
ahora desde la Administracin central debera de haber comenzado diez aos
antes de que realmente naciese. La lentitud de los proyectos nacionales son
difcilmente asumibles por la gil dinmica que precisan los Ayuntamientos.

Personalmente creo en un nomencltor nacional de alto valor aadido. Creo en
las virtudes de ese gestor de I.G., no obstante tambin estoy convencido de que dicho
sistema slo ser til para la Administracin en general si se contempla en su
desarrollo un equipo tcnico formado por ingenieros de las distintas administraciones
o en su defecto, se creen comisiones de trabajo eficientes para conocer la realidad de
las distintas necesidades y dar respuesta a las mismas. Es decir un Organismo en el que
trabaje personal de todas las Administraciones implicadas (Estatal, Autonmica,
Provincial y Municipal) en el seno deseable del I.G.N.

Sobre lo anterior, slo a modo de observacin y respecto a conversaciones
mantenidas con responsables de proyectos nacionales he encontrado muy
frecuentemente problemas de comunicacin. En algunos casos el interlocutor era
desconocedor de la componente espacial de un nomencltor (lenguaje informtico),
por otro lado he encontrado otros que tenan una alta cualificacin en nomencltores
(lenguaje geomtico), pero que no entendan una problemtica determinada, por el
slo hecho de que contemplan su proyecto autnomamente. El resultado en estos
casos, difcilmente dar solucin a las respuestas que del nomencltor requiere el
Ayuntamiento de Madrid o cualquier otro gran Ayuntamiento. As de claro.

ESTADSTICAS DE USO: EL CASO DE MADRID.

Se ha decidido meter las estadsticas de uso del nomencltor B.D.C. del
Ayuntamiento de Madrid en este apartado del estudio con la finalidad de dar una
perspectiva real del uso que sobre un nomencltor municipal se realiza. Hemos de
tener en cuenta que slo aplicaciones y servicios municipales hacen uso de l y que
aqu slo reflejaremos las estadsticas de uso en tiempo real directo del nomencltor.


No se tendrn en cuenta en estas estadsticas:
- El uso del servicio web
- El procesamiento en diferido (BATCH)
- La carga de informacin en BBDD forneas
- El envo, recepcin o tratamiento de datos

Por tanto se detallar el uso de aplicativos en su trabajo cotidiano en jornada
laboral o a travs de las aplicaciones de internet activas al ciudadano.

Podemos adelantar aqu que B.D.C. mantiene dos entornos, uno mainframe y
otro distribuido, ambos en paralelo. En principio se pretenda migrar todas las
aplicaciones a una arquitectura distribuida, sin embargo hoy en da el estado de cosas
nos obliga a mantener dos entornos de nomencltor. Las estadsticas fiables son las del
entorno distribuido, mientras que las del uso del nomencltor en el mainframe son
estimaciones en base a muestras.

Nomencltor B.D.C. distribuido

El nomencltor distribuido naci de forma efectiva en el ao 2005 con la
primera aplicacin que migr desde el mainframe (Padrn municipal de habitantes).
En el momento actual, un total de 44 aplicaciones usan el nomencltor como parte
integrada de sus aplicaciones de gestin o S.I.G. Algunas de sus caractersticas son un
espacio de datos en disco de 3 Gb + 2 Gb para ndices del SGBD. El nmero de registros
es de 14.918.062 distribuidas en un conjunto de 82 tablas alfanumricas ms 3
espaciales. Estas ltimas dentro de nodos o conformando raz del diseo del entorno
SIG municipal denominado SIGMA (Sistema de Informacin Geogrfica Madrid).



Uso porcentual del espacio en disco por parte del SGBD (SqlServer 2005)

Pero a dirio Cunto usan el nomencltor las aplicaciones municipales? Para
verlo usaremos dos aos relativamente significativos como para comprender el
alcance del mismo y su progresin en los ltimos aos:

- Ao 2009. El volumen de llamadas fue de 4.443.362 durante todo el ao y el
nmero de consultas directas a travs de servicios de nomencltor de consulta
de la intranet fue de 68.577 consultas y 1.811 listados.
- Ao 2012. El volumen de llamadas ha sido (hasta noviembre) de 77.001.316
llamadas al nomencltor. El nmero de consultas directas a travs de intranet a
B.D.C (hasta noviembre) ha sido de 186.805 (345%) y se han solicitado 1.034
listados inmediatos.

Como podemos ver el nmero creciente de aplicaciones conectadas, unido a la
adaptacin de los usuarios y el incremento de los servicios telemticos produce un
incremento exponencial en el uso del nomencltor de Madrid o BDC.



Uso directo de personal municipal sobre sobreutilidades del nomencltor en intranet

Uso directo de aplicaciones de gestin o S.I.G. por llamadas a consultas sobre el nomencltor
(intra-internet)

La ltima auditora en mainframe sobre muestreo de uso por parte de las
aplicaciones an vivas en dicho entorno es de Marzo de 2010. Es seguro que el nmero
accesos ha aumentado respecto a dicha fecha por la aparicin de aplicaciones nuevas
como subsistemas de los existentes. No obstante la variacin no debera ser
significativa, por lo que consideraremos como vlidos los de aquella valoracin.


En 2010 el nmero de accesos se obtuvo por muestreos de 4 horas de jornada
laboral que se extrapolaron a una jornada completa. Los muestreos se hicieron en
distintos horarios y das con el fin de obtener una muestra correcta. El resultado que
arroj es que al ao se produce una media de 43.401.000 accesos estimados, lo que se
corresponde con una carga total sobre el nomencltor municipal del 36%, sin embargo
en el momento actual la carga que soporta el mainframe en cuanto a procesamientos
nocturnos es an superior a la realizada en el entorno distribuido.

Es evidente que contemplando este volumen de uso (estamos hablando de ms
de 120 MM [3,8 peticiones por segundo durante 24h todos los das del ao] de
llamadas slo en tiempo real) se entienda mejor todo lo que llevamos estudiado hasta
el momento.

Uso de BDC (nomencltor Madrid) en llamadas de tiempo real



4
EXPOSICIN

Despus de haber realizado un viaje histrico por el nomencltor haciendo
especial incidencia en su vertiente madrilea y analizar la realidad existente en Espaa
y como se hace necesario un nomencltor municipal en grandes urbes vamos a
analizar algunos aspectos bsicos para poder estudiar y comprender el porqu de las
soluciones geomticas que se estudiarn despus, enfocndolas desde la perspectiva
de la ciudad de Madrid.

Por lo tanto el objetivo de la presente exposicin ser:

- Comprender conceptos bsicos y sus problemas bajo el enfoque de la ciudad.
- Conocer las distintas tecnologas a nuestro alcance.
- Comprender la base lgica bsica sobre la que se debe de sustentar el
nomencltor bajo nuestra perspectiva.

Solo de este modo podremos afrontar con garantas de comprensin las bases
fsicas y de procedimientos que despus sern estudiadas.



CONCEPTOS Y ELEMENTOS PREVIOS

El conocimiento profundo de los elementos que intervienen en el nomencltor
de cualquier municipio es bsico para afrontar con garantas el problema. Como dijo
Virgilio Feliz el que ha llegado a conocer la causa de las cosas!. Bien, pues
empecemos a conocer las cosas para poder luego poderlas afrontar causalmente y en
consecuencia poder dar las mejores soluciones.

Muchas veces se tiene una visin excesivamente ligera de lo que constituye un
nomencltor. Parece algo obvio que todos tenemos en la cabeza y con lo que hemos
convivido desde que nacimos prcticamente. Bajo esa perspectiva son como las
estrellas que miramos cada da y cuya composicin, reacciones y geofsica no nos
paramos a analizar. Vamos a estudiar esos elementos (al menos los bsicos) que
constituyen el interior de nuestra estrella:

EL CALLEJERO Y SUS ELEMENTOS

La calle est tan ligada a nuestra cultura, a nuestra forma de ser, que los
refranes, parte de nuestra ms interiorizada educacin popular las nombran en
numerosos casos:

- Me trae por la calle de la amargura
- Por la calle del ya voy se va a la casa del nunca
- Calle mojada, caja cerrada
- De la calle vendr quien de tu casa te echar



Todos sabemos lo que es un callejero en esencia. Una ciudad est compuesta
de calles con tipologas diferentes y con identificadores en ellas que sirven tanto para
orientarnos, como para identificar un lugar dado.

Un callejero, tambin denominado a veces como maestro de vas gua
urbana cuando va acompaado de cartografa auxiliar, siempre es un callejero,
estemos en Espaa, en Inglaterra Street file o en Francia Rpertoire des rues y sus
caractersticas en nuestro entorno son similares, an con pequeas diferencias, que en
Europa y en general en el mundo Occidental son mnimas.

El callejero tiene como parte principal del nomencltor intrnseco de una
ciudad tres misiones principales:
- Organizar nominalmente el espacio urbano sin equvocos ni contradicciones.
- Optimizar el envo de informacin y su calidad. Centralizando su labor
conseguimos aumentar an ms el ahorro ms que considerable que supone
un buen nomencltor y un correcto uso del mismo. Empresas como Experian
Quas con presencia en 9 pases dan una idea del negocio y la creciente
demanda del este servicio en el sector privado.
- Vertebrar el proceso de desarrollo de una poblacin. En nuestro mundo
occidental y en concreto en Madrid ya nos hemos olvidado del Madrid del S.
XVIII con su problemtica, pero en numerosos pases, como dijo Eduouard
Dayan en 2009, director de la Unin Postal Universal (Organismo de la ONU) es
urgente acometer la organizacin de las direcciones de las ciudades. Entre las
consecuencias que provoca no tener un domicilio destacan:

o Marginacin de comunidades
o Problemas de voto y difcil acceso a una identidad legal completa
o Dificultad de obtencin de crditos y cuentas bancarias
o Problemas para acceder a servicios pblicos bsicos (agua, luz, telfono)



Como podemos apreciar el callejero va mucho ms all de lo que en un
momento inicial podemos pensar y representa un motor esencial no slo para la
economa (ciudad desarrollada), sino tambin para el desarrollo social (ciudad en vas
de desarrollo).

Callejero es una palabra derivada de calle (del latn callis is, senda o camino)
que se puede definir como sistema de identificacin de los espacios pblicos de una
poblacin delimitados superficialmente consistente en una asignacin nominal
concreta de cada una de ellos con la que se pretende sea conocido de forma oficial y
en cuyo dominio es aconsejable rijan principios de ordenacin interior, sean estos
geomtricos, aritmticos, alfabticos o una combinacin lgica de ellos.

Por extensin y ya hablando de callejeros geomticos es habitual que adems
se codifiquen literales relativos al denominado hueco o local (local 10, 2 B ).

Veamos pues, dentro del mbito de un callejero municipal que si logramos un
nivel mximo de abstraccin tendramos tan slo dos elementos principales, al que
sumaremos un tercero para lograr un enfoque completo:

- Nombre de calle
- Nombre de portal
- Otros

Calle (ThoroughfareNameValue)
Una calle tendr una representacin nica en la ciudad, de manera que su
identificacin sea inequvoca, es decir desde la perspectiva de nuestro S.I. una calle
deber de tener una clave primaria (normalmente numrico) desde el momento
mismo de su nacimiento, que ninguna otra calle compartir nunca.


Esquema bsico relaciones de un callejero con mximo nivel de abstraccin

En el apartado del captulo anterior Tipologa del nomencltor municipal ya
vimos sucintamente cual es el proceso de alta de denominaciones para nuevos viales,
el cual se debe de ajustar para el caso de Madrid, a la normativa AMN 1981/1 de 30-
04-1981 y publicado en el BOAM n 4402 de 11/06/1981 entre las pginas 571 y 573.
Existen una serie de recomendaciones, entre las cuales se da mxima importancia a
topnimos preexistentes instando a su mantenimiento. Las nicas excepciones para
una denominacin de una va o espacio pblico literalmente especificadas son:

1. No se utilizarn nombres de personas vivas, salvo que su relevancia cientfica,
literaria o artstica est pblicamente reconocida dentro y fuera de nuestras
fronteras.
2. Tampoco debern utilizarse nombres que por su ortografa o fontica puedan
inducir a error o provocar hilaridad.


3. No se repetirn nombres ya existentes en el callejero madrileo, aunque se
trate de aplicarlos a vas o espacios pblicos de distinta naturaleza o se
presenten bajo formas aparentemente diversas, pero referidas a la misma
persona (o acontecimiento).
Con respecto a su ubicacin, las normas del Ayuntamiento de Madrid son:
1. La rotulacin de las vas pblicas deber estar colocada a la entrada y salida de
las mismas, y en el supuesto de calle de varios tramos, las placas se situarn
tambin a la entrada y salida de cada uno de ellos, procurndose que dicha
rotulacin resulte visible tanto de da como de noche.
2. Los rtulos de las calles respondern a dos modelos solamente: uno
correspondiente al casco antiguo y otro nico modelo para el resto.
3. En los rtulos de vas de nueva denominacin se agregar, en su caso, la
profesin o carcter ms destacado del personaje que d nombre a las mismas.

Una vez nacida una calle con su correspondiente denominacin, esta podr
tener a lo largo de su vida varios nombres. Las causas de un cambio de denominacin
pueden ser muy variadas. Tcnicamente en el Ayuntamiento de Madrid se autorizan
cambios de denominaciones en los siguientes supuestos:

1. Por exigencias urbansticas.
2. Para hacer desaparecer duplicidades derivadas de la unin de trminos
municipales.
3. A peticin de las Juntas de distrito.

Efectivamente, el punto dos ha sido utilizado a raz de la anexin a Madrid de
municipios limtrofes (La C/ guila por ejemplo exista adems de en Madrid, en
Chamartn y en Hortaleza) y el punto tres, es habitual detectarlo en las tramitaciones
de expedientes de modificacin de denominaciones de va. Sin embargo, aunque se


Una calle de vila con su denominacin actual e histricas. Fte- Antonio Romero

producen casos, es extrao detectar los del punto uno, ya que el propio carcter de las
operaciones urbansticas sobre zonas consolidadas suele acarrear mayoritariamente la
desaparicin del vial. Un ejemplo lo tenemos en el plan de actuacin sobre las casas de
vivienda social de los 50 de la calle Monte Torozo y alrededores (Distrito de Puente de
Vallecas), que ha supuesto la reurbanizacin de la zona. Gracias al comparador
urbanstico que forma parte del presente estudio es sencillo comprobarlo.



Pero la realidad suele ir ms all y adems de los anteriores supuestos nos
encontramos otros por lo cuales las denominaciones de va se ven modificadas.
Agunos ejemplos de ello son:

Motivos polticos y/o vecinales

Existe una perversa costumbre de politizar las calles. El Departamento de
Cartografa sabemos que en la proposicin de nuevas calles vela porque la realidad
toponmica se considere, pero en muchos casos las calles adquieren nombres
aspticos, oportunistas o temticos que en mi opinin personal no respetan ese
carcter toponmico o alusivo a la historia o hechos del lugar que muchas veces podra
hacerse.

Sin embargo, lo anterior es mejor que el sesgo que proporcionan las ideologas
polticas. As en 1936 la Calle Gran Va pasa a denominarse Avenida de la C.N.T., en
1939 pasa a denominarse Avenida de Jos Antonio para volver a su nombre original en
1980. Durante la I Repblica (1873) esto pas con numerosos nombres de calles con
referencia al rey o a la monarqua y en general es un mal perpetuo de la capital de
Espaa.

No pensemos en cosas del pasado solamente. En la actualidad y a raz de la
aprobacin de la Ley de Memoria Histrica del 2007 se va a obligar a muchos
municipios a grandes modificaciones en su callejero.

Al mismo tiempo esta Ley ha promovido un nmero de instancias por parte de
AAVV y otras. As en el acta de sesiones de la Junta Municipal de Salamanca de
29/11/2011 se formula la proposicin n 2011/1225371 relativa al cambio de
denominacin del Pasaje del General Mola, o esa otra que est recogiendo firmas, con


el fin de tener un apoyo constatado al cambio de la denominacin M Teresa Senz de
Heredia por la de Jos Couso para el barrio de Ventas, dentro del distrito de Ciudad
Lineal.

Noticia publicada en el diario digital madridiario.es

Creo que la Ley de Memoria Histrica para los nomencltores podra
aprovecharse en los casos posibles para retrotraerse a aquellas denominaciones no
politizadas, de manera que no se incurra continuamente en el mismo despropsito.
Por ejemplo el Pasaje del General Mola podra volver a ser el Pasaje de Sud Amrica
(as escrito), mientras que personajes como M Teresa Senz de Heredia, que son el
nombre inicial de la calle (absorbiendo el fondo de saco de Santa Felicidad) , han de
considerarse por su carcter histrico (en especial con referencia a la ciudad de
Madrid) obviando la componente poltica y ser justo con el personaje y su relacin con
nuestro municipio (parece que el personaje ejemplo, es cierto que simplemente tiene
carcter de seora de Jos Luis de Arrese).



Otro tipo de dislates, segn mi modesta opinin es el eliminar calles con
historias ligadas a personajes con la del nombre personaje. Es el caso de la casa en
donde vivi Vicente Aleixandre, que desapareci (C/ de Wellingtonia) para pasar a ser
la C/ Vicente Aleixandre. Adems este cambio se produce en el ao 1977,
contradiciendo un punto de las normas de 1981 (en realidad no es contradiccin
porque dichas normas no existan, pero era seguida como norma no escrita).
Aleixandre, que muri en 1984 segn dicen, tampoco estuvo nunca de acuerdo con
dicho cambio, lo cual es el colmo. A quin le gusta vivir en su propia calle?

Equivocaciones tipogrficas

Sobre las equivocaciones tipogrficas en la denominacin de una calle, existen
diversas corrientes. Unos piensan que al constituir simplemente equivocaciones, han
de ser subsanadas, sin dejar huella histrica de dicho cambio. Probablemente es cierto
y dichas incidencias tan slo deberan aparecer en la BBDD como documentos
digitalizados anexos que debidamente fechados den idea de los periodos de tiempo en
los que el error ha estado vigente. Otra corriente sin embargo dice que si se usan
callejeros centralizados, dicho nombre deber de aparecer como historia del mismo.
Personalmente pienso que se debe de tratar dicha casustica documentalmente, salvo
que el nombre aprobado fuese errneo de origen (en la documentacin aprobada) y
haya precisado una modificacin plenaria, caso contrario y adems de realizar la
oportuna anotacin documental, ser necesario crear variantes para el nombre con
dichas equivocaciones (esto evitar que llegando un documento a trmite con error,
ste se siga propagando).

Errores tipogrficos en una calle de Mlaga. El correcto es Thuillier. Fte- Web ciudad jardn de Mlaga


Errores de concepto
A veces la caracterstica intrnseca de identificacin que lleva un callejero se ve
alterada, de manera que poner dos calles de nombre similar y del mismo tipo (calle,
avenida, pasaje) en confluencias slo da lugar a problemas de identificacin y
orientacin por lo que no deberan de darse en mi opinin.

La mala eleccin del nombre de dos calles que confluyen crea problemas - Fte web Alicante vivo test

Portal (LocatorDesignator)

Los portales, o numeraciones de las calles son una organizacin de sus accesos
de manera que la localizacin de una posicin a lo largo de la misma sea sencillamente
identificable. En general se considerarn numeraciones aquellos accesos a la va que
partan de viviendas individuales o colectivas, garajes y otras similares. Los locales
comerciales se consideran un hueco ms y se relacionan a travs de dicho portal y una
numeracin en el caso de Madrid, a travs de una aplicacin diferenciada denominada
censo de locales. En el caso de las urbanizaciones con portales interiores, el
Ayuntamiento califica la numeracin a travs del alfabeto.

En las denominaciones de las calles existe un desequilibrio entre el control
promovido desde la Administracin tendente al orden y al cumplimiento de cuanto
legisle el poder. En palabras de Javier G. Sola de la U.C.M. lo policial se expresar


como cuidado de la plis, como manifestacin de un poder que desea mantener la
ciudad como una unidad, entendida bajo un criterio: el control. Frente a ella se
encuentra la lgica del pueblo con su propio criterio (que no tiene porqu ser malo).
Un criterio libre que nombra al callejero por lo que siempre escuch y mejor pareci.
As por mucho que en el 1939 la Glorieta de Atocha pasase a llamarse Plaza del
Emperador Carlos V, por mucho que la Plaza de Fernndez Ladreda no se llame Plaza
Elptica, por mucho que la Puerta de Alcal no lo sea por cuanto es la Plaza de la
Independencia o La Plaza de Neptuno deba ser la de Cnovas del Castillo el
Ayuntamiento dir y el pueblo dispondr y as en ese equilibrio se sobrevive sin
problemas.

Pero llegados a la numeracin la cosa cambia. El ciudadano se considera
agredido por el Ayuntamiento Quin es el Ayuntamiento para cambiarme a m el
nmero?... Ese es un terreno que muchos ciudadanos consideran propio. Se aaden
adems las dificultades de una complicadsima planificacin, salvo en zonas de nueva
urbanizacin. Complicacin, que con acierto y superficialidad en Febrero de 1955
trataba un columnista de la redaccin del diario ABC.


En Madrid la primera numeracin que se realiza de las calles se realiz a efectos
fiscales en poca de Fernando VI (1749), constituyendo un ejemplo de planificacin
catastral importante que cumpli su objetivo fiscalizador, al tiempo que regul un
orden en la ciudad con el fin de gestionar adecuadamente la carga de aposento (un
tributo para los madrileos por estar la corte en ella). Se trata de la llamada
planimetra general de Madrid y el resultado fueron 557 planos y tres libros de
asientos de casas. Para ello varios inspectores se dividieron la ciudad basndose
mayoritariamente en el plano de Teixeira sobre el cual zonificaban el trabajo en base a
las manzanas, que eran numeradas (al final del trabajo se realiz una renumeracin
con el fin de que no hubiese duplicados de manzana). La Visita General consista en
visitar cada una de las casas de dichas manzanas, estimar superficies y dems
parmetros de clculo del impuesto y comprobar escrituras de propiedad, de manera
que cuando la casa haba quedado visitada se le asignaba un nmero dentro de su
manzana (de sur a norte), resultando en Madrid 557 manzanas con 7049 casas.

Artculo sobre la problemtica de la numeracin en Madrid- Fte. Hemeroteca ABC 20/02/1955


Realizado el trabajo se colocaron las placas de identificacin de cada una de las
manzanas, de manera que las puertas (casas) quedaban numeradas tambin.

A la izda placa de Manzana. A dcha placa de casa dentro de manzana - Fte pgina Arte en Madrid

Hoy en da la mayora de casas que mantienen estas placas no son de la poca,
pero han dejado las placas en las nuevas construcciones, de manera que han llegado
hasta nuestros das e incluso resultan de inters para la investigacin. El sistema en si
mismo ya era algo, era un sistema de identificacin, tal vez no muy acertado, pero lo
era. El gran inconveniente fue el no establecer como elemento de numeracin la calle,
sino la manzana, ya que lo que suceda es que la duplicacin de nmeros por cada calle
era abrumadora en ocasiones y la realidad del madrileo de a pi era que empez a
usar aquella numeracin anteponiendo el nombre de la calle, lo que creaba confusin
en la localizacin de casas.

El sistema ideado para la planimetra general de Madrid estuvo vigente hasta el
ao 1834, el mismo ao de la brutal epidemia de clera que acab con el 2,6% de la
poblacin madrilea, quedando en 175.000 habitantes. En ese ao el Marqus de
Pontejos, Alcalde de Madrid, ante el caos de la cantidad de duplicaciones de nombres


de calles y la imposible numeracin, sumado al crecimiento urbanstico y poblacional
de la ciudad, decide llevar a cabo un proyecto de identificacin de la ciudad, tomando
medidas que dieron lugar a la eliminacin de ms de dos centenares de
denominaciones de calles y el estudio de una nueva numeracin. El sistema utilizado y
an ms ambicioso lo haba apuntado el literato Mesonero Romanos (concejal de
Madrid en el periodo 1845-1850) que muy interesado por el Urbanismo visit varias
ciudades europeas en su libro Manual de Madrid escrito tres aos antes (1831) de
que se realizase la reforma de Pontejos.

Madrid en sus diarios (1830-44) del Instituto de estudios madrileos 1961 Fte : U. Massachusetts



Extracto del libro MANUAL DE MADRID de 1831 de Mesonero Romanos

Por ltimo la legislacin actual sobre numeracin es bastante sucinta y se
explica en la ya nombrada Norma sobre denominacin y cambios de nombre de vas y
espacios pblicos urbanos de 30/04/1981:
1. Para la numeracin de las calles servir de referencia la Puerta del Sol,
asignndose nmeros, de menos a ms, segn la cercana a sta. Los nmeros
pares irn a la derecha y los impares a la izquierda. Podrn, no obstante,
tomarse en consideracin centros geogrficos de otros conjuntos urbanos,
cuando la referencia anterior no resulte posible.
2. La numeracin de las plazas ser correlativa, siguiendo el sentido de las agujas
del reloj.



Tipologa de los nombres de las calles de Madrid en relacin con las de Barcelona segn estudio de la
Revista HISPANIA-NOVA. N 9 (2009)

Otros (PostalDescriptor, AdminUnitName etc)

Por constituir los dos elementos fundamentales del nomencltor propio o
intrnseco hemos preferido estudiar pormenorizadamente tanto las calles como las
numeraciones, no obstante, no podemos olvidar dos aspectos importantes:

- Deben de contemplarse los nomencltores metropolitanos y estatales, para lo
cual ser necesario el conocimiento de poblaciones, la provincia a la que
pertenecen y al menos una lista de pases recogida de la lista oficial del INE
(vara segn lo hacen nuestras relaciones diplomticas), as como realizar
asociaciones bsicas de inters al nomencltor BDC de la ciudad.
- Deben de integrarse datos asociados a la realidad urbanstica del callejero
dentro del nomencltor intrnseco o propio: Edificios, particiones de viales
(calzada, acera, otros), tipologa de portales, alturas, restricciones
planeamiento, geometra y asociaciones topolgicas, etc.
- Deben de asociarse al nomencltor propio tambin informaciones de carcter
general y libre segn la LPD (Ley de proteccin de datos), vinculable o de


asociacin lgica con el callejero. As ser de inters asociar la siguiente
informacin mnima:

o Divisin administrativa del municipio
o Divisin censal.
o Divisin postal y enrutamientos postales en su caso.
o Divisiones normativas (reas restringidas, reas de proteccin acstica
o medioambiental, Servicios de estacionamiento regulado)
o Divisiones operativas (Referencia catastral parcelaria rstica y urbana)
o ndices de fiscalizacin (ndice fiscal, zona fiscal)
o Puntos de inters municipal o ciudadano

En el Ayuntamiento de Madrid todos los datos relativos al carcter urbanstico
del nomencltor propio, as como su cartografa dependen administrativamente del
Departamento de Cartografa del rea de Gobierno de Urbanismo y Vivienda, mientras
que aquellos datos no urbansticos o urbansticos pero de fuentes externas asociados
al nomencltor propio, as como toda la adquisicin de la informacin y
mantenimiento de los nomencltores metropolitanos y estatal corresponde a la
Seccin de Base de Datos Ciudad del Servicio de Poblacin y Ciudad del Organismo
Autnomo Informtica Ayuntamiento de Madrid.

TOPONIMIA DE LA CIUDAD

La toponimia (del griego toto (topos) lugar y ovoo (onoma) nombre) de la
ciudad constituye parte del nomencltor de la misma. Normalmente esta se
considerar de forma especial en el nomencltor propio, no obstante tambin se
podr considerar en el metropolitano (si se considera necesario) y los diseminados del
estatal.

Aunque comnmente se habla de toponimia y toponomstica como sinnimos,
es bueno establecer una diferenciacin, como bien nos dice E. Coseriu, de manera que
la toponomstica deber de ser conocida como la ciencia que estudia la toponimia. No


obstante y como decimos, es habitual confundir ambos trminos en los escritos.
Tambin se suele imponer el trmino toponomstica cuando hablamos de topnimos
de lenguas, dialectos distintos al propio o bien trnsitos de la propia. En Espaa es
frecuente que los estudios de toponimia Gallega, Vasca, Catalana, Aranesa, Leonesa,
Bable o Asturiana, Aragonesa o las hablas de trnsito como el extremeo, el murciano
o el canario antepongan dicho trmino. Tambin se suele utilizar la divisin
toponimia/toponomstica, empleando el primero para los topnimos con nombres de
lugar y el segundo para topnimos con nombres propios. Personalmente creo que son
sinnimos puros ya que su significado es el mismo y su raz nica. Creo que se trata
ms de disquisiciones cientficas corporativas que de diferencias que nos conduzcan a
nada til ni concreto, entendiendo que a las anteriores diferencias se les pueden
atribuir nombres o subtipos con un contenido semntico descriptivo y por lo tanto
capaz de hacer ms inteligible aquello que se quiere expresar.

Modo de catalogacin de topnimos establecido por la Comunidad Autnoma Valenciana

El I.G.N. en la normativa toponmica del MTN25 define topnimo como
nombre propio con el que se designa una entidad topogrfica Se le conoce tambin
como nombre geogrfico. Con frecuencia est formado por un trmino genrico y
otro especfico <<Sierra>> <<de Segura>>. Se dice tambin que el trmino genrico


expresar la naturaleza del topnimo, mientras que el especfico identificar a aquella
de forma singular.

La acepcin nombre geogrfico como sinnimo de topnimo no me parece
acertada por parte del IGN, ya que aunque en su mbito especfico si podra
establecerse un paralelismo justificado, ha de tenerse en cuenta que la toponimia
representa un subconjunto de nombres geogrficos. Por poner un ejemplo no me
parece correcto en la definicin de mesa decir al final tambin se le conoce con el
nombre de mueble, porque mueble es ms genrico que mesa al igual que nombre
geogrfico es ms genrico que topnimo (las denominaciones del callejero de una
ciudad son nombres geogrficos que sin embargo no son topnimos). Creo que el IGN
como referente de la cartografa nacional debe de establecer definiciones y
comparaciones generales y no slo que afecten a su idiosincrasia propia.

El topnimo es un concepto basado en un eje en el que deben de confluir el
espacio o situacin del elemento con al menos otro que en general tendr como
origen el lenguaje (la toponomstica se emplea tambin con esta acepcin), la
geomorfologa (caracterstico del trmino genrico de un topnimo) o la historia (M.
Trapero dice en la toponimia han quedado preservados, como fsiles, muchos
elementos lingsticos caractersticos de pocas pasadas, a la que yo aado y
tambin elementos histricos).

Dependiendo del estudio que deseemos realizar de los topnimos, estos
debern de dividirse segn el objetivo ltimo de dicho estudio, de manera que si
tenemos palabras derivadas de trminos zoolgicos (zonimos) hablaremos de
zootopnimos, si nos interesa la botnica o fitologa, sus nombres sern fitnimos y
asentados en un lugar sern denominados fitotopnimos, los referidos al Santoral se
denominarn hagitoponimos, los odotoponimos sern los relativos a accesos a
poblaciones, los ortoponimos se referirn a accidentes orogrficos, talasotopnimos
cuando hablemos de mares y ocanos etc.

Sin embargo hay dos divisiones especialmente tiles y totalmente aceptadas en
la toponomstica que veremos en lo largo de la exposicin que sigue.



Clasificacin segn la lengua del lugar del topnimo

- Exnimos : Nombre del topnimo en otra lengua a la que hablan los habitantes
del lugar en el que se encuentra el topnimo.
- Endnimo: Nombre del topnimo en la lengua autctona del lugar en el que se
encuentra el topnimo. Tambin llamados autnimo o etnnimo.
- Topnimos Hbridos: En zonas bilinges se da el caso de que parte del
topnimo se encuentra en una lengua y otra parte en otra. La recomendacin
del IGN es la traduccin a ambas lenguas y utilizarlos en una u otra lengua
dependiendo del pblico al que se dirija (tipo de hablante). Mi visin personal
es que este tipo de topnimos representan una cualidad, contienen riqueza en
s mismos y por lo tanto no deberan ser traducidos a ninguna de las dos
lenguas, sino dejarlo en estado puro.

El grupo de expertos de las Naciones Unidas (GENUG)(O.N.U.) define endnimo
como un nombre geogrfico utilizado en la forma (o la transcripcin) exacta de la
lengua del lugar (topos) y del territorio donde la lengua habiendo producido esta
forma es el idioma oficial. Cualquier otra forma es un exnimo y la ablacin de los
signos diacrticos basta para crear un exnimo. A veces los exnimos y endnimos se
utilizan indistintamente (ej: griegos y helenos).

Con visin tcnica, creo que la poltica, al igual que suceda con el callejero,
entra en terrenos cientficos y culturales en los que no debera de estar presente. Es
evidente que Ourense es un endnimo de un lugar cuyo exnimo castellano es Orense,
es evidente que lo mismo ocurre con Lleida y Lrida. No se trata de que los exnimos
de esas provincias sean advenedizos y aunque otros puedan tener un cierto sentido
como puede ser el caso de Girona, son demasiados los casos en los que no se ha
atendido a razones cientficas, sino a otras que desconocemos. Cuando un endnimo o
exnimo es reciente sigue siendo topnimo, pero ira contra el propio origen del
topnimo su creacin artificial. En este sentido la convivencia oficial del
endnimo/exnimo debera persistir debiendo ser a m entender ORENSE/OURENSE, al
igual que se ha hecho muy acertadamente con CASTELLN/CASTELL, por ejemplo. La
riqueza en conocimientos, nunca debiera perderse. En el caso del oficial Girona,
resulta imposible pronunciarlo para los castellano parlantes tal y como se nos ofrece.


Es tal el desacuerdo con respecto a ello que la Real Academia de la Lengua, en su
diccionario de dudas (Diccionario Panhispnico de Dudas) dice:

Gerona: Nombre tradicional en lengua castellana de la provincia y ciudad de
Catalua cuyo nombre en cataln es Girona. Salvo en textos oficiales, donde es
preceptivo usar el topnimo cataln como nico nombre oficial aprobado por
las Cortes espaolas, en textos escritos en castellano debe emplearse el
topnimo castellano. El gentilicio, para todo tipo de textos, incluidos los
oficiales, es gerundense.

Mapa de 1553 de Hyeronimus Cock Arriba ORENSE, abajo LIRIDA, LERIDA?, no LLEIDA


Otra divisin de topnimos aceptada mundialmente es en funcin de la
extensin e importancia superficial del topnimo (aqu incluimos como nueva la
nanotoponmia, que ser la considerada dentro del mbito municipal, definiendo las
dos primeras en concordancia con lo sealado por Lzaro Carreter):

- Toponimia mayor o macrotopnimo: Estudia los nombres de lugar de grandes
extensiones (pueblos, ros, montes, valles)
- Toponimia menor o microtoponimo: Estudia los nombres de lugar de
extensiones medias (arroyos, solanas, riscos)
- Toponimia de detalle o nanotopnimo: Estudia los nombres de lugares de
extensin pequea, normalmente dentro de una poblacin o adyacente a ella
(lugares, mercados, fuentes, edificios o su agrupacin y elementos urbanos que
definan una extensin de la misma con independencia del callejero oficial y que
resultan de uso habitual para ciudadanos y viajeros)

En Espaa, los Organismos con capacidad para normalizar y modificar un
topnimo (mayor y menor) son los siguientes en el caso de la Comunidad de Madrid
(Las CCAA bilinges y el principado de Asturias tienen prcticamente toda la
competencia en materia de toponimia, auxiliados tambin por sus Centros
Cartogrficos Autonmicos y sus respectivas Academias de la Lengua):

Instituto Geogrfico Nacional
- Organismo de referencia nacional
- Siempre que no haya legislacin, ni autoridad expresa
- Toponmia suprautonmica
- Genera nomencltor geogrfico nacional.

Real Academia Espaola

Comisin Especializada de Nombres Geogrficos. Consejo Superior Geogrfico

Registro de Entidades Locales. Ministerio de Poltica Territorial (AAPP)


- Inscripcin nombres oficiales (provincias, municipios, comarcas,
mancomunidades municipales). Recibe modificaciones de las CCAA que
no sern oficiales, mientras no estn en este registro.

Comunidad de Madrid
Gobierno de la Comunidad de Madrid
Consejera de Presidencia, Justicia e Interior
Direccin General de Cooperacin con la Administracin Local
- Pueden modificar nombres oficiales (provincia, municipio, islas con
competencias administrativas, entidades de mbito inferior al municipio,
comarcas con competencias administrativas y cualquier otra agrupacin
municipal) que sern comunicadas al Registro de Entidades Locales del M
AAPP. El caso de modificacin del nombre de la Comunidad Autnoma o de
las provincias, requiere adems ser aprobado por las Cortes Generales.
Adems las Comunidades Autnomas pueden crear y modificar topnimos
de su titularidad o gestin propia (puertos martimos si son autonmicos,
espacios naturales autonmicos, bienes de inters cultural). En ningn caso
ros, parajes, picos, sierras, fuentes, lagos, casas y resto de toponmia son
competencia del IGN (salvo, ya hemos dicho en las CCAA bilinges y
Asturias)

La normativa del Ayuntamiento de Madrid AMN 1981/1 de 30-04-1981 y
publicado en el BOAM n 4402 de 11/06/1981 dice:
- Podr tambin conferirse denominacin oficial y atribuirse nombre propio a
conjuntos urbanos perfectamente delimitados y con una cierta separacin de
su entorno geogrfico y hasta a edificios singulares, si se considerase
conveniente a efectos de intensificacin toponmica.
- La eleccin de nombre para la denominacin de vas y espacios pblicos
urbanos es, por su propia naturaleza, libre y discrecional. Se tendr en cuenta
en esta eleccin la denominacin anterior del lugar donde aqullos estn
situados, si resulta conocida y merece ser respetada.

En el Ayuntamiento de Madrid, cualquier modificacin o alta de un topnimo,
como sucede tambin con viales y segn el artculo 3 aprobado por el Pleno municipal


a fecha 27 de Julio de 2006 referido Por el que se establece la organizacin y
estructura de los Distritos y se delegan competencias en las Juntas Municipales den los
Concejales Presidentes y en los Gerentes de los Distritos dice que los Gerentes tienen
entre sus funciones aprobar para su elevacin al Pleno a travs del rea de Gobierno
respectiva, la asignacin y cambio de denominacin de vas y espacios pblicos,
conjuntos urbanos, edificios singulares, parques, centros comerciales de barrio y
mercados de Distrito.

Por lo tanto el Ayuntamiento tendr la capacidad, no slo de reflejar los
topnimos oficiales en su nomencltor (obligacin), sino aadirle la riqueza que para el
mismo representarn los nanotopnimos y que son de gran inters para la ciudad. As
pues, el Ayuntamiento de Madrid refleja con especial cuidado toda la toponimia de la
que resulta afectado, sin olvidar aquellos lugares que para su adecuado gobierno son
imprescindibles. Supongamos una estacin de metro en la que se ubica una
determinada tienda, pues bien, la misma est sujeta a una serie de normativas y
tributos a las que desde BDC hay que dar respuesta.

Pantalla de la consulta de internet del nomencltor propio del Ayto de Madrid.
Argelles es un nanotopnimo vigente como estacin de metro.



Como dice Julio Caro Baroja, La toponimia es un elemento de conocimiento de
la antropologa y de la etnologa, fundamental para tener una imagen del medio segn
pobladores de distintas pocas y de distinto origen. En Madrid son muchos los rastros
toponmicos que se encuentran de lo que un da fueron y quedaron sepultados tras el
crecimiento de la urbe tras los cuales podemos obtener esa imagen:

Las aguas

Madrid, situada en un altiplano encierra bajo ella mantos acuferos alimentados
por los arroyos subterrneos y la de lluvia almacenando en balsas recubiertas de capas
impermeables el agua que hasta la creacin del Canal de Isabel II (CYII) los madrileos
consumieron. Fuencarral, Chamartn, Canillas y Canillejas elevados sobre la almendra
central permitan que sus aguas descendieran por gravedad hasta la capital, mediante
sistemas hidrulicos ya usados en la poca musulmana, de manera que al llegar dicha
agua a la capital abasteca a las distintas fuentes. Hasta tal punto es mtica el agua de
Madrid que hay quien piensa (errneamente a nuestro entender) que el nombre de
Madrid (referencia de Jaime Oliver Asn) procede del de Mayras (canales subterrneos
de agua). Como sabemos la referencia es a arroyo matriz (Matrice-Mayrit) del que ya
hablamos en su momento.

Primer levantamiento altimtrico preciso de Madrid realizado por los ingenieros Juan Rafo y Juan Rivera
en 1848 para el estudio de mejora de abastecimiento de agua de Madrid. El conocimiento altimtrico de
la ciudad era lgicamente imprescindible- Fte Hispagua



Los arroyos de Madrid eran el Arroyo de la Castellana (el de Maudes,
desembocaba en l) que depositaba sus aguas en el Arroyo Abroigal y desembocar en
el Manzanares. El arroyo de Leganitos por la cuesta de San Vicente, metindose en
terrenos de Palacio, al que vertan aguas el Arroyo del Arenal y el Arroyo de las
Minillas, en la zona de Principe Po, para finalmente desembocar cerca del Puente de
Segovia. Aguas arriba del Manzanares tenamos el Arroyo de San Bernardino y ms
arriba el de Cantarranas, as como al Oeste el Arroyo de Meaques. Otros arroyos que
han dejado su impronta en Madrid son Arroyo Molinos, Arroyo Fresno, Arroyo
Fontarrn o Arroyo de las Negras.

Los caminos

El urbanismo de la ciudad en su crecimiento ha tendido a crecer haca el norte y
el este (las zonas ms llanas), evitando el sur a todas costa debido a su ms abrupta
orografa. Como ejemplo de caminos con realidad toponmica actual tenemos el de
Francia al norte, el de Alcal al este. Estaban los de Chamber y Hortaleza, el camino
del convento de San Bernardino, el camino de Fuencarral, el camino de la fuente de la
Castellana y el camino de Ronda (actualmente desglosado en Marqus de Urquijo,
Alberto Aguilera, Carranza, Sagasta y Gnova.), que discurra por la muralla
conectando todas las puertas. Otros seran el de Amaniel o el de Alcobendas,

Las puertas

Las puertas que durante su historia ha tenido Madrid, tambin son interesantes
para plasmar el hecho de que la realidad toponmica de Madrid no es arbitraria. Como
principales destacaremos las de Conde Duque, San Bernardino, Fuencarral, Los Pozos o
Bilbao, la de Santa Brbara, la de Recoletos, el portillo de las Maravillas, Puerta de
Alcal, Atocha, la de Toledo y la puerta de la Vega.

Lejos del carcter de impronta, que queramos resaltar como importancia de la
toponimia en el callejero de la ciudad, la nanotoponimia debe de cuidarse


especialmente, pues constituye como la toponimia fuente futura de informacin sin
olvidar su carcter identificador de la ciudad y de respeto a nuestros antepasados.

En las pantallas siguientes veremos algunos ejemplos de topnimos de la
ciudad para despus dar a conocer el nmero de ellos en funcin de su divisin por
tipologa municipal. Algunos ejemplos de topnimos, que se pueden consultar a travs
de la web municipal ( http://www-2.munimadrid.es/ConsultasBDCWebSqlInternet/jsp/index.jsp )
son (Ejemplos que veremos: urbanizacin, parque, parroquia, polgono, colonia,
barranco, lugar y mercado):





Nota.- Ntese que la opcin Ver Mapa est activa. La componente espacial de los topnimos es
intrnseca al propio concepto, aunque en ocasiones sus lmites no pueden ser ms que estimados.

En el caso ms complejo la numeracin de calles puede estar asociada a uno o
ms elementos toponmicos bien por el carcter geomtrico de interioricidad, bien
por el de cercana. En algunos casos, esto puede tener su razn de ser a efectos de
tareas municipales si los lmites del topnimo pueden definirse con precisin
(Cuntos habitantes tiene el barrio del pozo del to Raimundo?. Este nombre no es un
barrio oficial, sino un topnimo concreto de una zona definida del barrio de Entrevas,
dentro del distrito de Puente de Vallecas).

El Ayuntamiento de Madrid da una gran importancia a los topnimos como
reflejo de la riqueza histrica y evolutiva de la ciudad y en la actualidad han sido
identificadas 3.501 ocurrencias. Algunos elementos toponmicos y nmero de
ocurrencias que se reflejan desde el nomencltor propio son los siguientes:



TOPNIMO OCURRENCIAS TOPNIMO OCURRENCIAS
LUGAR 402 BARRIO 39
EDIFICIO 264 CASA 38
COLONIA 245 FUENTE 34
PARQUE 175 PUERTA 27
POLIGONO 85 URBANIZACION 26
BARRANCO 70
ARROYO 53
MERCADO 51
CERRO 42
COMPLEJO 42
POBLADO 40

En otro orden de cosas las divisiones administrativas competencia del
Consistorio tambin son reflejo de la realidad toponmica, de manera que, como
noticia reciente de cambio tenemos el de un distrito de Madrid, el de San Blas
Canillejas, antes slo San Blas. La Junta Municipal el 20 de Junio de 2012 aprob la
elevacin a Pleno municipal de la demanda de cambio de denominacin, lo que fue
aprobado por el Pleno del Ayuntamiento que finalmente abord la modificacin del
reglamento orgnico de los distritos de la ciudad de Madrid de 23 de diciembre de
2004. Es cierto que en este caso los vecinos han tenido que luchar duro por su
topnimo (ms de cuatro lustros). Realmente el distrito de San Blas es en su origen el
de Canillejas (Canillejas y Canillas estaban agrupados en un mismo Ayuntamiento en
1866, segn dice la crnica de la provincia de aquel ao), habindose formado San Blas
despus, como forma de lgica continuidad hasta los lmites nuevos propuestos de la
ciudad iniciada en el plan de urgencia social de Madrid de 1957 con un plan de 20.000
viviendas. As una nueva zona urbana quitaba hasta su orgullo nominal a muchos siglos
de historia de un pueblo. San Blas siempre ha sido San Blas, a veces unido a Hortaleza
(Distrito de San Blas- Hortaleza) otras solo, pero Canillejas haba quedado relegado.
Canillejas, por orgenes debera ser el nombre del distrito, pero se ha preferido el
nombre de San Blas-Canillejas, que tambin responde a la realidad toponmica del
distrito y cuya decisin me parece acertada. Slo un pero: Por qu no se ha
modificado el barrio llamado Canillejas perteneciente al mismo distrito?. Villa de
Canillejas, Canillejas Pueblo u otras que responderan mejor a la situacin del distrito y
relacin histrica.



El Ayuntamiento de Madrid, codifica los caminos como viales, no constituyendo
verdaderos nanotopnimos. Algunos se codifican como redes si no tienen oficialidad
pero si nombre conocido. Adems de topnimos tambin en Madrid se utiliza un
concepto muy similar al de topnimo, pero utilizado en el mbito del propio callejero.
Se trata de aquellas calles que teniendo nombre oficial, son reflejadas tambin por los
madrileos con otros nombres, que deben preservarse con el adjetivo de popular.
Algunos ejemplos de Madrid de nombres populares frente a oficiales son:

- CAMINO ANTIGUO DEL FERROCARRIL YESERO
- CALLE ARROYO DEL PLANTIO
- AUTOVIA CALLE 30
- JARDIN CAMPO DEL MORO
- CAMINO CASTILLEJOS
- PARQUE EL CAPRICHO
- GLORIETA ELIPTICA
- PASEO ESTATUAS
- FUENTE ISABEL II
- AUTOVIA MADRID A COLMENAR VIEJO
- CAMINO MOLINO VIEJO
- LUGAR MONTAA ARTIFICIAL
- PLAZA NEPTUNO
- CAMINO PALOS
- CARRETERA PARQUE ATRACCIONES
- PARQUE SAN BLAS
- CAMINO SAN FERNANDO DE HENARES
- CAADA SANTISIMO

Por ltimo y aunque esto ya no pueda ser considerado exactamente topnimo
del lugar, sino elemento lineal de inters para el municipio (cabra aqu una discusin),
se codifican todas las redes de la ciudad cuya publicacin no represente una revelacin
de elementos sensibles desde el punto de vista de seguridad para la ciudad pudiendo
ser identificadas con independencia de los topnimos al no ser clasificados en nuestro
caso como tales.



LOS CONCEPTOS DE VARIANTERO, DICCIONARIO Y FONO

Una direccin puede entrar en un sistema geomtico de nomencltor de
mltiples maneras. Se pretende que la entrada de direcciones sea un proceso
controlado que minimice los errores en la codificacin de dicha direccin.
Evidentemente surgen problemas derivados de ello lo que puede comprometer su
fiabilidad.

Segn Theodore Johnson un dato es totalmente correcto cuando:
- Es preciso (grabacin correcta del mismo)
- Est completo (todos los datos bsicos se registraron)
- Es nico (no existe otro dato igual en el sistema)
- Es actual (se mantiene vivo en el tiempo actualizado)
- Es temporalmente correcto (concepto temporal del dato)
- Es consistente (todas las relaciones establecidas desde-hacia l son posibles)

Las direcciones no son estticas en cuanto a su concepcin como dato y tendr
un recorrido informtico que simplificadamente puede resumirse en:
- Recopilacin del dato.
- Entrada del dato al sistema.
- Almacenamiento del dato.
- Integracin del dato en el sistema.
- Recuperacin del dato.

Evidentemente la recopilacin del dato es una labor que depende en gran
medida de la fuente o recursos propios y su calidad se gua por mtodos ajenos al
proceso en s, pero es importante, pues si partimos de una recopilacin errnea,
lgicamente el problema surgir desde el inicio.



Los problemas de entrada de datos (Data Gathering) al sistema se pueden
realizar tomando dos alternativas. Por un lado tendremos una entrada mediante
interaccin humana con el sistema (tiempo real) y otra totalmente automatizada
(procesos por lotes o BATCH). El primer caso, (salvo entrada espagueti en un solo
campo) no es objeto de estudio en este momento y se realizar basado en validaciones
sobre campos en los que la informacin queda perfectamente organizada, de manera
que el actor recibir continuas ayudas para mejorar la informacin. Por otro lado un
proceso automatizado precisar de elementos que en cierto modo sustituyan esa
actividad humana.

El almacenamiento del dato y su integracin en el sistema es bsico. Aqu un
buen diseo de la BBDD que contendr al nomencltor, as como una correcta
organizacin de la misma incluyendo la temporal como parte inseparable de una
direccin constituye un elemento que si no es considerado dar lugar a problemas en
el mantenimiento y posiblemente generar errores en la informacin.

Por ltimo a la hora de extraer el dato habr que considerar de nuevo su
componente temporal, debiendo ser esta la correcta, pues de lo contrario el receptor
obtendr resultados perversos.

La optimizacin de los datos de nuestro sistema debe de considerar tanto el
aspecto de calidad a la entrada, como mantenimiento en el interior del sistema. En
este apartado estamos considerando la entrada al sistema, que en un proceso de
retroalimentacin servir para su mantenimiento

En la entrada de datos por procesos BATCH es interesante crear unos
estndares, unas normas conocidas y unos formatos con el fin de que todo aquel que
quiera utilizar el nomencltor conozca los criterios mnimos que debe cumplir para
integrar los suyos propios. Es el concepto en definitiva de metadato. Debemos de
publicar los metadatos de interaccin con el sistema.



Desde el punto de vista del desarrollo debemos de considerar que Murphy
siempre tiene razn. El anlisis ms despiadado de todo lo que pueda ocurrir en la
entrada es fundamental para conseguir unos resultados ptimos. Para ello haremos
uso de las tcnicas de limpieza (Data cleaning, cleansing o scrubbing son sinnimos),
minera de datos (Data mining) y tcnicas de bsqueda de sucesos de exploracin de
datos. Los tiempos de preproduccin y prueba-ensayo-error son fundamentales, pero
muy complicados de realizar.

En el caso en el que la informacin sobre la direccin venga en espagueti y
estos procedan de mltiples orgenes desconocidos, la alternativa ms eficaz hasta el
momento es el uso de tcnicas de procesamiento de lenguaje natural (PLN). Una
direccin en espagueti podr ser considerada un modelo estocstico (sucesin de
variables aleatorias) que ser discreto por lo que podr ser resuelto
probabilsticamente por las cadenas de Markov en donde la probabilidad de que se d
un evento depende del evento anterior. Dentro del contexto de PLN (NLP en ingls)
podemos usar herramientas como GEPPETTO, ALEP, GATE, ADYN pero tambin
podemos realizar procesos propios que simulen las caractersticas concretas del
contexto de direcciones, que resulta una particularidad mnima de un PLN. Como
hemos dicho, en direcciones del tipo espagueti ser cuando tendr sentido tratar el
dato como un modelo oculto de Markov (HMM), al que podremos
aplicar el algoritmo de Viterbi para encontrar la secuencia de informacin ms
probable. (Un anlisis terico de los modelos de Markov puede ser estudiado en
profundidad en la tesis doctoral de Moiss Pastor i Gadea titulada: Aportaciones al
Reconocimiento Automtico de Texto Manuscrito (UPV).

En un proyecto PLN de direcciones existen dos fases: una que ser de prueba
del modelo y otro por el que aadiremos nuevas caractersticas a cada diccionario o
variantero con lo que obtendremos nuevas matrices de probabilidad de sucesos, con el
fin de optimizar el reconocimiento de la estructura de la direccin para cada vez un
conjunto mayor de circunstancias. Se trata de retroalimentar al sistema y recalcular
sus probabilidades cada cierto periodo de tiempo en base a la experiencia (el sistema
es tanto ms eficaz, cuanto ms similares sean los datos de entrada a los considerados
en la muestra extrada para el llamado entrenamiento de la muestra de generacin del
modelo oculto de Markov). El xito de este sistema se basa en tener la muestra ptima
para cada tipo de informacin que nos llegue (Si recibimos informacin de este tipo de


varios Organismos o empresas, lo ideal es tener juegos contrastados), siempre y
cuando los formatos de envo no sean alterados (las pautas de organizacin del
espagueti no varen). Un modelo de Markov se suele dar por vlido cuando se supera
el 80-90% de aciertos.

Aspecto de retroalimentacin de un variantero o los ficheros lexicn de un PLN



Detengmonos un momento para explicar sucintamente el proceso aplicado al
caso que nos ocupa:

Proceso de clasificacin y ordenacin de palabras de entrada- Fte: Tesis doctoral Paloma Fernndez
Martnez

Es aconsejable que los diccionarios de sustitucin o lexicn (en realidad
solemos referirnos a lexicn cuando adems de sustitucin nos encontramos con
reglas en el diccionario) se hagan en base a la taxonoma de la direccin
(representarn cada uno de los elementos posibles o vectores), as tendremos un
diccionario de tipos de va, otro de calles, otro de numeraciones y si prevemos entrada
de datos de los subnomencltor metropolitano y estatal podemos tener otros relativos
a provincias, poblaciones y codificacin postal. Cada uno de ellos tendr sus propias
reglas bsicas de sustitucin change[C/;CALLE], change[av????da,av???da;AVENIDA]


para obtener las caractersticas avinguda, avenida etc. El uso de comodines ? para
caracteres y * para conjunto impreciso de caracteres es recomendable.

Posible taxonoma para elemento calle (vectores diferentes) - Fte- Liudmila Padrn

Supongamos partiendo del ejemplo taxonmico propuesto que nos
encontramos con las siguientes direcciones (origen):

1. C/ ALCAL N 7, 4B
2. CL ALCALA DE GUADAIRA 3
3. ALCALA DEL RIO NUM 7

Nuestro sistema a travs del diccionario ser capaz de proponernos el siguiente
(etiquetado automtico de los vectores):
1. C/ ALCAL N 7, 4B [PREFIJO][NO PREFIJO][NUMERO][NUMERO ORDINAL][LETRA]
2. CL ALCALA DE GUADAIRA 3 [PREFIJO][NO PREFIJO][UNKNOW] [NO PREFIJO] [NUMERO]
3. ALCALA DEL RIO NUM 7 [NO PREFIJO][UNKNOW] [UNKNOW] [NUMERO]



Todos los elementos desconocidos de la muestra [UNKNOW] se etiquetarn
obligatoriamente como parte del elemento que creamos correcto (vector correcto):
[NO PREFIJO] en nuestro caso, obteniendo (etiquetado final). Notese que se arrastra la
informacin (UN) al asignado que proviene de un cdigo desconocido previamente.
1. C/ ALCAL N 7, 4B [PREFIJO][NO PREFIJO][NUMERO][NUMERO ORDINAL] [LETRA]
2. CL ALCALA DE GUADAIRA 3 [PREFIJO][NO PREFIJO][ NO PREFIJO-UN] [NO PREFIJO] [NUMERO]
3. ALCALA DEL RIO NUM 7 [NO PREFIJO][ NO PREFIJO-UN] [NO PREFIJO-UN] [NUMERO]

As que tendremos una aproximacin de cmo viene estructurada la
informacin de entrada en base a los diccionarios taxonmicos proponindonos
respuesta (salida).
1. CALLE ALCALA NUM 7 4 B
2. CALLE ALCALA DE GUADAIRA NUM 3
3. ALCALA DEL RIO NUM 7

Una vez seleccionada la muestra y adecuados los diccionarios para optimizar su
correcto uso, se realizan los clculos de la muestra de Markov, para la cual se utiliza la
muestra de etiquetado final a partir del cual obtendremos tres elementos.
a) Probabilidad de inicio o de que cada vector (diccionarios) de la direccin
comience por una taxonoma determinada (3 ocurrencias en nuestro caso):

- [PREFIJO] = 0.6666667
- [NO PREFIJO] = 0.3333333
- [NUMERO] = 0
- [NUMERO ORDINAL] = 0
- [LETRA] = 0
Nos queda pues el vector matriz: [0.66, 0.33, 0.00, 0.00, 0.00]
b) Probabilidad de transicin o matriz A de Markov o de que cada vector sea
seguido por otro vector que puede ser l mismo u otro.



En este caso siempre tendremos una matriz cuadrada cuyas filas y columnas
estarn compuestas por cada uno de los vectores posibles. Lo ideal es primero
calcular las ocurrencias de cada vector para despus calcular la probabilidad.

OCURRENCIAS VECTOR
3 PREFIJO
7 NO PREFIJO
3 NUMERO
1 NUM ORD
1 LETRA

La matriz de probabilidad de transicin entre vectores quedar entonces:

VECTOR
A
PREFIJO
A
NO PREFIJO
A
NUMERO
A
NUM ORD
A
LETRA
De PREFIJO 0 1 0 0 0
De NO PREFIJO 0 0,57 0,42 0 0
De NUMERO 0 0 0 0,33 0
De NUM ORD 0 0 0 0 1
De LETRA 0 0 0 0 0

(Por ejemplo, de la tabla, podemos ver que la probabilidad de que detrs de un
no prefijo vaya otro no prefijo es del 0.57 o en tanto por ciento 57%, ya que un


[no prefijo] pasa a otro [no prefijo] en 4 ocasiones de las 7 posibilidades que
tena de hacerlo p=[4/7])

Para entender el concepto, la probabilidad de que se d la secuencia de
estados siguiente: [NO PREFIJO] [NUMERO] [NUMERO ORDINAL] [LETRA] es
0.33 (inicial) x 0.42 x 0.33 x 1 (transiciones) = 0.045

c) Probabilidad de emisin u observacin o matriz B de Markov. La matriz A
representa una situacin de probabilidad de salida esttica y si slo usramos A
la probabilidad de una determinada combinacin es calculable directamente
por lo que en ese caso hablamos del modelo observable de Markov. Sin
embargo el utilizar la matriz B adems nos permite el conocer la distribucin de
probabilidad de que se d una determinada salida en funcin de todas las
posibles alteraciones intermedias. Ahora sin embargo seremos incapaces de
conocer los estados intermedios y slo podremos observar el resultado final,
por lo que al quedar opacados todos estos resultados de estados de clculo
hablamos del modelo oculto de Markov. Esta frmula se puede interpretar
como el nmero medio de veces que un determinado valor o smbolo
representa un estado final.



VALOR VISTO
DE
PREFIJO
DE
NO PREFIJO
DE
NUMERO
DE
NUM ORD
DE
LETRA
DE
UNKNOW
Y ES PREFIJO 1 0 0 0 0
0
Y ES NO PREFIJ 0 0.5714 0 0 0
0.4285
Y ES NUMERO 0 0 1 0 0
0
Y ES NUM ORD 0 0 0 1 0
0
Y ES LETRA 0 0 0 0 1
0

Por ejemplo de las 7 veces que aparece un estado NO PREFIJO proviene 3 veces
de un smbolo UNKNOW (3/7)=0.4285.

Con el fin de no hacer cero las posibilidades de distribuciones (matriz B) se
suele suavizar la distribucin, de manera que sin desvirtuar la matriz en funcin de las
posibilidades de que un determinado smbolo (6 smbolos) sea un estado concreto (5
estados) se suele suavizar el conjunto de manera que este coeficiente de suavizado
ser para cada una de las filas (distribucin por estados):

N smbolos que van a l Ki=Coef de suavizado 1 / (N+S)
PREFIJO 2 0.125
NO PREFIJO 7 (4+3 de Unknow) 0.076
NUMERO 2 0.125
NUM ORD 1 0.142
LETRA 1 0.142

S= Smbolos identificados = 6 (PREFIJO, NO PREFIJO, NUMERO, NUM ORD, LETRA, UNKNOW)

Nuevo valor suavizado de b (i, j) = ABS (b (i, j)-(b (i, j)*Ki)) + (Ki/S)

Por ejemplo para nuevo tendremos:

b(2,2)=ABS(0.5714-(0.5714*0.076))+(0.076/6)=0.05402930



PREFIJO NO PREFIJO NUMERO NUMORD LETRA UNKNOW
PREFIJO 0,8958333 0,0208333 0,0208333 0,02083333 0,02083333 0,0208333
NO PREFIJO 0,0128205 0,5402930 0,0128205 0,01282051 0,01282051 0,4084249
NUMERO 0,0208333 0,0208333 0,8958333 0,02083333 0,02083333 0,0208333
NUMORD 0,0238095 0,0238095 0,0238095 0,88095238 0,02380952 0,0238095
LETRA 0,0238095 0,0238095 0,0238095 0,02380952 0,88095238 0,0238095

Se pueden realizar otros suavizados distintos al enunciado, pero pensamos que
el enunciado puede dar buenos resultados. Como vemos la suma de probabilidades de
que un determinado smbolo est en un estado es 1 (suma de fila).

Esquema de actuacin en un MOM hasta conseguir la efectividad de 89% - Ft: Lumidla Padrn (ETECSA)

Una vez que tenemos nuestra vector matriz inicial y las matrices A y B podemos
aplicar el algoritmo de Viterbi que nos da la secuencia ptima de estados para la
cadena de entrada, determinando la secuencia de estados que recorre (secuencia
oculta) y as obtener la ya comentada ptima o mejor dicho ms probable. Ello se dar
cuando encontremos que un elemento de la direccin es encontrado como dos
estados (imaginemos que Fuenlabrada, se puede asignar al estado poblacin y al
estado nombre de va). Habr que calcular la probabilidad de las dos cadenas y
quedarnos con la ms probable como buena. Otro ejemplo de aplicacin del algoritmo
ser cuando tengamos UNKNOW no asignables, de manera que tendremos que
calcular la probabilidad de que ese UNKNOW est asociado a uno u otro estado,
quedndonos con el ms probable.


Imaginemos que nos llega la siguiente cadena:

VALLE TIETAR NUM 10

Y que despus de pasar por los diccionarios, nos la simboliza en:

[NO PREFIJO][UNKNOW][NUMERO]

Veamos como actuara el algoritmo de Viterbi (para UNKNOW tendremos 6
casos, que son los estados de nuestro sistema ejemplo):

Camino 1 (producto de probabilidades): [NO PREFIJO][PREFIJO-UN][NUMERO]

- Probabilidad de que empiece por NO PREFIJO : 0.3333
- Probabilidad de que el smbolo NO PREFIJO se corresponda con el estado NO
PREFIJO: 0.5402
- Probabilidad de que de NO PREFIJO pasemos a PREFIJO: 0
- (en cuanto encontramos un cero la multiplicacin dar 0, luego se anula
camino = 0)

0.0 = probabilidad 1

Camino 2 (producto de probabilidades): [NO PREFIJO][NO PREFIJO-UN][NUMERO]

PREFIJO: 0.5402
- Probabilidad de que de NO PREFIJO pasemos a NO PREFIJO: 0.5714
- Probabilidad de que el smbolo UNKNOW se corresponda con el estado NO
PREFIJO: 0.4084
- Probabilidad de que de NO PREFIJO pasemos a NUMERO: 0.42
- Probabilidad de que el smbolo NUMERO se corresponda con el estado
NUMERO: 0.8958



0.3333 x 0.5402 x 0.5714 x 0.4084 x 0.42 x 0.8958 = 0.0158 = probabilidad 2

Camino 3 (producto de probabilidades): [NO PREFIJO][NUMERO-UN][NUMERO]

PREFIJO: 0.5402
- Probabilidad de que de NO PREFIJO pasemos a NUMERO: 0.42
- Probabilidad de que el smbolo UNKNOW se corresponda con el estado
NUMERO: 0.0208
- Probabilidad de que de NUMERO pasemos a NUMERO: 0
camino = 0)


Camino 4 (producto de probabilidades): [NO PREFIJO][NUM ORD-UN][NUMERO]

PREFIJO: 0.5402
- Probabilidad de que de NO PREFIJO pasemos a NUM ORD: 0
camino = 0)


Camino 5 (producto de probabilidades): [NO PREFIJO][LETRA-UN][NUMERO]

PREFIJO: 0.5402
- Probabilidad de que de NO PREFIJO pasemos a LETRA: 0
camino = 0)




En nuestro caso la cadena ms probable es el camino 2 [NO PREFIJO][NO
PREFIJO-UN][NUMERO], como efectivamente es. Hemos visto la operativa del
algortimo de Viterbi. Se trata de estudiar en l la probabilidad de cada posibilidad de
que una combinacin suceda. En realidad tendremos muchos casos en los que dos
diccionarios nos den valor para uno de los elementos y que haya varios UNKNOW para
un registro determinado, de manera que el problema se complica con un nmero de
combinaciones altsimo. En nuestro caso es evidente que el modelo entrenado es
insuficiente, pues lo lgico ser que tengamos probabilidades para la mayora de los
caminos, cogiendo como ms probable aquella cuyo producto de probabilidades
sucesivas (modelo oculto) sea mxima.

Antes de seguir, slo comentar que adems del comentado algoritmo de Viterbi
es interesante a efectos tericos conocer la probabilidad de una determinada
secuencia a priori. La manera ms ptima de solucionar este problema es a travs del
algoritmo de avance-retroceso que simplemente apuntamos para su conocimiento.

Los modelos de Markov, se utilizan tambin en tiempo real para organizar la
informacin antes de que el sistema pueda buscar a travs de la BBDD. En este caso se
suelen dar como respuestas proposiciones concretas finales, mientras que una entrada
estructurada permite ayudas ms precisas.

Si la informacin de entrada BATCH al nomencltor se produce a travs de una
informacin debidamente integrada a travs de formato de metadatos, entonces el
mtodo que consideramos ms eficaz a largo plazo es el de varianteros combinados.

Existen dos metodologas al respecto en funcin de si podemos realizar anlisis
a priori o no:

- Anlisis a priori de datos: Este procedimiento es aconsejable en arranques del
sistema con gran volumen de datos o migraciones. Se pretende que la entrada


de datos no vlidos se minimice, para lo cual realizamos un primer paso con
un proceso de obtencin de variables no encontradas (por ejemplo municipios),
de manera que les asignaremos un peso en funcin del nmero de ocurrencias
con respecto al total de errores en la misma variable. Esas variables de peso
igual o superior al 5% deberan de formar parte del variantero (para este tipo se
suele emplear la palabra variantero, aunque el uso de diccionario, tambin
sera vlido a nuestro entender). En el ejemplo siguiente vemos distintas
variantes utilizadas para la poblacin MADRID utilizadas por la BDC en el

MADRIE MAFRIDD 2ADRID
MADRIED MAIRD 3154ID
MADRIF MAJDRID 35DRID
MADRIFF MAJRID 3ADRID
MADRIKD MAKDRID 4ADRID
MADRIO MALDRID 51DRID
MADRIOD MANDRID 5ADRID
MADRIR MANOTERAS 6986ID
MADRIS MADRID 6ADRID
MADRIUD MAODRID 7039ID
MADRIX MAORID 7ADRID
MADRIZ MAQDRID 8ADRID
MADROD MARDI 9138ID
MADROID MARDID 9143ID
MADRONA MARDRID 91DRID
MADRTID MARID 9ADRID
MADRUD MASDDRID AADRID
MADRUID MASDID ADRID
MADRXID MASDIRD .ADRID
MADSIRD MASDIRD 0ADRID
MADSRID MASDRI D 1ADRID
MADTID MASDRID MAERID
MADTRID MASDRIRD MAFRID
MADXRID MASEDIRD MASRID
MAEDRID MASIRD
Un extracto de variantes reales para procesos batch - poblacin
Madrid



- Anlisis a posteriori de datos: Este procedimiento es el usado cuando no hay
tiempo para realizar anlisis a priori o en procesos de no gran volumen (menos
de 500.000 registros de entrada), en un sistema existente, en el que no existir
un volumen suficiente de informacin como para ponderar la incidencia de una
determinada variante nueva. As la sucesin de procesos generar pasado un
determinado tiempo un conjunto nuevo suficiente de datos que podr dar
lugar a la generacin de nuevas variantes. El problema de analizar los datos a
posteriori es la necesidad de haberlos integrado en el sistema, lo que obliga a
procesos ulteriores de mejora de la informacin. Sin embargo, esta forma de
proceder puede ser aprovechada como oportunidad para la mejora de
informacin a registro completo en futuras entradas. Los anlisis a posteriori
requieren de aplicaciones especficas que realicen todas estas tareas y
permitan a los gestores realizar las equivalencias de forma cmoda.

(Ver junto a pantalla siguiente)


Dos pantallas de la aplicacin de gestores del nomencltor para inclusin de variantes al mismo. Vase
la opcin de recarga de variantes y consolidacin de datos .Fte Ayuntamiento de Madrid

En el Ayuntamiento de Madrid y en lgica consonancia con la importancia
porcentual con el uso de cada uno de los nomencltores y para hacernos una idea de
las variantes podemos decir que a finales del 2012 existen 4119 variantes de calles de
la ciudad, 2725 variantes de nombres de poblaciones de la provincia de Madrid y 1517
variantes de poblaciones fuera de la Regin madrilea.

Por ltimo como sistemas de integracin de informacin es interesante conocer
tres conceptos que normalmente suelen ir ligados. Hablamos de los conceptos fono,
grafo y distancia fontica, los cuales van ligados comunmente al anlisis de la
informacin de entrada en tareas de tiempo real, en las que un usuario interacciona
con el sistema.

Los llamados fonos (fono es sonido) y grafos (grafo es dibujo) son en definitiva
palabras que forman parte del nombre de una entidad (o que fontica [fono] u
ortogrficamente [grafo] se confunde). As por ejemplo tendremos que ALTOS DE


MADRID se descompondr en dos grafos ALTOS y MADRID bsicos a los que
iremos aadiendo algunos otros. En cuanto a fonos, tendremos por ejemplo ALTO,
ARTO, MADRI, MATRIT, MADRIZ etc. El sistema permite de forma rpida
encontrar valores ms probables de la entrada del dato para entradas escritas y
habladas a distancia (sistemas de atencin telefnica). Es un sistema en el que la
alteracin en el orden de apellidos de personajes o nombres propios resulta de inters
(Si por ejemplo ingresamos una direccin Juan Mendizbal lvarez, el sistema nos
reconducir a Juan lvarez Mendizbal gracias a los grafos. En otros casos nos
propondr una lista ordenada por una doble ordenacin probabilidad+alfabtica que
resulta de gran inters.

Combinada con la anterior o tambin de uso a posteriori en las cadenas de
Markov se usa la distancia fontica. La distancia fontica o distancia de edicin se
define como la distancia o diferencia entre dos cadenas. As la distancia fontica es el
nmero de operaciones mnimas para convertir una cadena en otra. Las ms
comunes son la distancia de Hamming y la de Levenshtein. La distancia de Hamming
slo admite sustitucin de caracteres, por lo que presupone que el nmero de letras
ha de ser el mismo entre dos cadenas a comparar (TENRE Y TENER). El anterior sistema
es bastante eficiente en tiempo de edicin (justo al finalizar la escritura de la palabra) y
la usan normalmente los mejores editores de texto (Word, por ejemplo). En nuestro
mbito, sin embargo, la ms usada es la de Levenshtein. En una distancia fontica de
Levenshtein se pueden eliminar, aadir o modificar letras de la palabra. En cualquier
caso una palabra ser ms parecida a otra o tendr ms posibilidades de querer haber
sido la misma cuanta menor sea su distancia fontica. El caso extremo ser la
distancia cero con lo que las palabras sern exactamente iguales. Una variante de la
distancia de Levenshtein es la variante de Damerau, que a las anteriores funciones
aade la de transposicin o cambio de la posicin de dos letras de la misma palabra.
En definitiva se trata en el fondo de la unin de las distancias de Hamming y
Levenshtein. El algoritmo de Levenshtein es de sencilla programacin, aunque como
siempre su coste es tiempos es exponencial, que es lo que hace que haya muchos
estudios sobre el mismo, cuyo fin es el de conseguir la deseada optimizacin de
tiempos (Ver el algoritmo de Heikki Hyyr de la Universidad de Tampere Finlandia).



EL CONFLICTO MULTILINGE

Ya se vio como las lenguas pueden representar una pesadilla en cuanto a la
rigurosidad toponimica, hasta el punto en el que lo cientfico se mezcla por desgracia
con una incorrecta visin en el que la lengua es usada no ya como elemento
enriquecedor de la toponimia, sino como objeto arrojadizo. En este sentido la
tendencia es el desplazamiento de una de las lenguas cooficiales, lo que demuestra a
mi modo de ver la cortedad de miras en la resolucin del problema toponmico.

Sin embargo aqu trataremos el conflicto multilinge no desde ese aspecto, ya
visto en detalle en apartados previos, sino como elemento a considerar en todo
nomencltor de una gran AALL. Este carcter que destacamos aqu deber de ser
tratado de forma especial o diferenciada para aquellos municipios en los que la
cooficialidad de lengua se d en su territorio. Aqu la trataremos desde la perspectiva
de un municipio como el de Madrid, en el que dicha realidad no se da, pero en el que
debe considerarse no slo como manera o forma de aciertos en la integracin de
informacin, sino como una deferencia al ciudadano que habita dichas comunidades y
a los servicios postales de reparto.

Una herramienta bsica para realizar este tipo de tareas y aconsejable, primero
por ser documento oficial, pero tambin por lo completo que es, es el documento
Directrices toponmicas de uso internacional para editores de mapas y otras
publicaciones (IGN-2011) en el que se hace un recorrido por la toponimia multilinge
y las distintas abreviaturas recomendables en cada lengua.



Lenguas a considerar en tipos de va y abreviaturas Fte - IGN

Dado que el Ayuntamiento de Madrid no tiene mayores servidumbres que un
ptimo nomencltor para sus propias necesidades como municipio, el tratamiento
multilinge se reduce considerablemente. En el caso del Ayuntamiento de Madrid, se
realiza un tratamiento de informacin slo para aquellas direcciones en las que el tipo
de va se exprese en una lengua distinta al castellano, presumiendo que quien ha
inscrito la calle en otra lengua puede desear que el correo le llegue en forma similar,
de manera que, como expresin de deferencia se guardar en BDC con la dualidad
lingstica oportuna, en la que el castellano estar, seguido del registrado en otra
lengua y siempre y cuando esa particularidad est registrada como multilinge en el
nomencltor estatal (que en nuestro caso es para el nico que tiene sentido).

Por ejemplo nos parece una buena prctica que si un ciudadano con relacin
con nuestro municipio ha puesto que vive en KALEA BERTENDONA es porque tiene
como lengua primaria el euskera, de manera que en su relacin con el Ayuntamiento
de Madrid recibir las notificaciones en un formato del tipo CALLE[KALEA]


BERTENDONA. Creemos que es una buena prctica que adems representa un respeto
hacia la voluntad del ciudadano vinculado de alguna manera con nuestra ciudad. En el
caso del Ayuntamiento de Madrid, existen 79 variantes idiomticas peninsulares de
tipo de vial.

Envo de informacin a un ciudadano teniendo en cuenta sus preferencias lingisticas

En cualquier caso, nuestro sistema, no deber de ver extrao el uso de un tipo
de va en cualquier realidad lingstica de Espaa (al menos para lenguas cooficiales en
determinados territorios del Reino). En este sentido la recomendacin de BDC siempre
ha sido el iniciar cualquier consulta sin el tipo de calle en pantalla. La realidad de
duplicidades para un mismo nombre de va en la que la diferenciacin reside en el tipo,
hace aconsejable esta operativa con el fin de referenciar correctamente el lugar al que
nos queremos realmente referir. Pensemos en el ejemplo SAN VICENTE en Madrid:



Para direcciones de fuera de nuestro pas el nmero de casos se reduce de tal
manera que los esfuerzos a realizar deben de considerarse en extremo. En cualquier
caso deberemos garantizar un soporte bsico del SGBBDD al que optemos. Siempre
ser ms importante nuestra de cara a la ordenacin de documentos por ejemplo,
que poder integrar el alfabeto cirlico en nuestro sistema.

LOS SISTEMAS DE REFERENCIA Y EL PROBLEMA DE LAS TRANSICIONES

Actualmente el elipsoide base para Espaa es en el que se apoya el sistema de
referencia ETRS89, es decir el GRS80, que vino a sustituir al GRS67 (no utilizado en
Espaa) porque se haban manifestado problemas en la representacin de la forma,
tamao terrestre y su campo gravimtrico, de manera que hubo de replantearse su
formulacin para la realizacin de tareas geodsicas y geofsicas. En la red GNSS (1 cm)
el recalculo (ITRF-Marco internacional de referencia terrestre) es continuo debido al


movimiento de placas, de manera que como un constante cambio de
posicionamientos en la superficie terrestre hara inviable su uso a efectos prcticos, se
establece un ITRF para un ao concreto como base de clculo (en nuestro caso y para
la pennsula es el de la placa parada en 1989, es decir el ITRF89 con el que se calcul la
red IBERIA95, que es la parte correspondiente al territorio espaol de la red ETRF89
[European Terrestrial Reference Frame]). A partir de aqu y dado que el Sistema de
Referencia aconsejado para el nuevo elipsoide era el ETRS89 (CRS=EPSG:25830, segn
los estndares OGC), el IGN calcul para Espaa una materializacin de posiciones
fsicas a lo largo de todo el territorio que constituye la red REGENTE (5 cm) para los
territorios peninsulares. A efectos prcticos las diferencias entre el uso del elipsoide
GRS80 o WGS84 va ms all de la cienmilsima en el denominador del aplanamiento,
con lo cual para el tipo de operaciones realizadas en un nomencltor, las coordenadas
en uno y otro sistema y en la misma proyeccin lgicamente, viene a ser equivalente,
lo que representa grandes ventajas operativas de cara a las AALL, que vemos como un
uso creciente del callejero y sus utilidades se realizan sobre dispositivos mviles con
capacidades GPS (ETRS89 permite una integracin perfecta con GPS, GLONASS y
GALILEO).

http://www.glonass-ianc.rsa.ru/en/
http://www.gps.gov/systems/gps/control/
http://www.gsa.europa.eu/
Pginas web de control e informacin de GLONASS, GPS y GALILEO

Antes del ao 2007 el sistema de referencia cartogrfico nacional era el ED50
sobre elipsoide de Hayford (1950). A partir de esa fecha, oficialmente se aprob el
sistema ETRS89 como nuevo S.R. El proyecto REGENTE, entre otras cuestiones
posibilit el recalculo de su red al nuevo sistema, lo que supuso la generacin de una
malla suficientemente densa para la obtencin de parmetros precisos de
transformacin entre los sistemas ED50 y ETRS89.



Esta rejilla se realiz por el servicio de Geodesia del IGN para facilitar a los
ingenieros las transformaciones oportunas, de manera que se gener una primera
denominada sped2et.gsb, que ha sido sustituida recientemente por otro nuevo
recalculo denominado r2009v9.gsb (simplemente debe de ser sustituida en nuestros
procesos), ambas en formato NTV2 (formato canadiense ideado por Junkers y Farley

Resea de vrtice geodsico de la red REGENTE Fte IGN

en 1995 que permite almacenar varias mallas y sus parmetros de transformacin
despus de haber aplicado una compensacin en bloque sobre mmcc a partir de los
vrtices de la red base para el clculo). A partir de este fichero y el programa
suministrado para el manejo del formato llamado ed2et.bas, puede realizarse la
transformacin punto a punto en un modelo recursivo (actualmente creo que ya existe
una versin que permite la transformacin de ficheros, pero inicialmente no era
posible).



Evidentemente es complicado para un Ayuntamiento ser rpido en la
modificacin de la cartografa, de manera que lo que si estaba en nuestra mano era
poder suministrar la informacin que dependa del nomencltor BDC en ambos
formatos ETRS89 y ED50, si bien las aplicaciones internas seguiran usando el sistema
ED50 para guardar uniformidad con los sistemas cartogrficos municipales y sus
sistemas de informacin geogrfica (SIGMA), as lo que hicimos fue un programa
denominado BDC-CONVETRS89 en Visual Basic que a partir de un fichero fuese
cogiendo unas coordenadas cada vez que fuese llamado, realizase la transformacin
entre la proyeccin UTM (ED50) y la proyeccin de coordenadas geogrficas, realizar la
llamada al programa suministrado por el IGN y despus volver a realizar la
transformacin de geogrficas a UTM (ETRS89), cuyo contenido era devuelto al
programa llamante. De esta manera otros programas podan recoger coordenadas de
tablas que las contuviesen y cargarlas luego sobre un campo de dicho registro (en
campos ex profeso) las coordenadas transformadas. Este sistema ha estado disponible
desde el ao 2008 para portales de Madrid, cruces, puntos de inters y cualquier otro
caso que se nos haya demandado. Una ventaja adicional supuso el hecho de que al
estar preparados pudimos realizar pruebas de desarrollos sobre telfonos y sistemas
mviles con GPS, realizando entre otros las API oportunas para uso sobre mviles.

Diseo universal que permite la convivencia de dos Sistemas espaciales de referencia en el nomencltor



Muchos de los sistemas con los que trabajamos estn basados en posibles
entradas externas, de manera que dicha entrada ha de estar preparada para aceptar
un sistema u otro (ED50 o ETRS89). Internamente debamos de prepararnos para
devolver una imagen cartogrfica o el portal ms cercano a una posicin, tanto si las
coordenadas que nos entraban era de uno u otro sistema, con lo que con el fin de
contemplar un sistema universal y sabiendo que la densidad de portales en Madrid es
cercana a los 300.000 es factible utilizar un sistema de cercana de un dato conocido
(portal), sobre el que conocemos la transformacin aproximada Ix, Iy a aplicar al punto
incgnita. Esto, que constituira un error para otro tipo de aplicaciones no lo es en
nuestro caso, dadas las precisiones requeridas para los usos del nomencltor. Adems
Universaliza la solucin futura del problema, de manera que tenemos toda la
infraestructura en cuanto a campos en las tablas que lo requieren y parmetros de
entrada a travs de API (Application Programming Interface) o WS (Web Service), de
cara a futuros cambios de S.R.

Esta solucin se ha demostrado eficaz a lo largo del tiempo, primero porque
hemos sido capaces como nomencltor de dar una respuesta rpida (en 2008 pocos
Ayuntamientos podan disponer del sistema que nosotros tenamos implantado en
Madrid dando as cumplimiento a la Ley) a los nuevos interrogantes y peticiones que
se nos realizaban, al tiempo que conseguamos no influir sobre los sistemas
municipales que sabemos que en breve (2013), ya dispondrn de la cartografa en el
nuevo S.R.

Real Decreto 1071/2007 de 27 de Julio por el que las Cortes Generales aprobaron el nuevo sistema de
referencia cartogrfico para Espaa Fte : Boletn Oficial del Estado



MULTIENTORNOS, PLATAFORMAS Y SU PROBLEMTICA

A la hora de definir plsticamente un nomencltor resulta esencial el
conocimiento de la plataforma sobre la cual vamos a realizar nuestras operaciones. Un
sistema condiciona no slo los entornos en los que basaremos nuestro proyecto, sino
tambin las posibilidades que el mismo tendr. No hay sistemas mejores ni peores a
priori y la realidad es que debemos adaptarnos la mayora de las veces a una
arquitectura marcada por pautas que no siempre se corresponden con las necesidades
de un nomencltor.

No soy capaz de definirme con respecto a las herramientas GPL (licencia
general pblica de GNU). En realidad GNU como S.O. libre se disolvi al aunar sus
sinergias con Linux, que se ha quedado con el nombre por antonomasia de S.O. libre.
Realmente el software libre siempre que tenga licencia copyleft es confiable. Existe un
concepto equivocado y es el de la gratuidad. No existe nada gratis. Un nomencltor de
un municipio no puede mantenerse en un sistema que no tenga mantenimiento, ni
asistencia. La diferencia estriba simplemente en el coste inicial del producto, pero
debemos de realizar un estudio real de costes del sistema en su vida til y otros como
facilidad en la implementacin de versionados, respuesta de incidencia, resolucin de
la misma etc. Por otro lado la ventaja que venan teniendo las herramientas GPL al
disponer de una legin de seguidores dispuestos a aprender su sistema ya no es
propiedad del software libre. Prcticamente cualquier plataforma de coste te permite
descargar versiones gratuitas. Es el caso de Microsoft compaa que permite la
descarga de todas sus plataformas de desarrollo (SqlServer, Visual Studio C#, Vb etc)
sin limitaciones operativas ni temporales para uso personal y de estudio.

Lo que s creo evidente es que las plataformas libres estn permitiendo
desarrollos demasiado arriesgados para una empresa comercial y en ese sentido si
pueden estar marcando tendencias y abrindose sin complejos en mercados
emergentes como el de dispositivos mviles. Tecnolgicamente por ejemplo el uso del


nuevo NOSql (Not Only Sql) y las nuevas BBDD a las que se pretende eliminar ese
marcado carcter relacional como el archiconocido Cassandra o HBase (basadas en el
concepto de la BBDD propietaria de google denominada BigTable) hacen que los
tiempos de respuesta sean excepcionales al estar fundamentadas sobre columnas
dinmicas en las que un registro puede tener diferente nmero de campos que el
siguiente dentro de una misma tabla, lo que hace que la actualizacin de campos, as
como su acceso sea muy cmodo y rpido. Son especialmente interesantes de seguir
proyectos como ElasticSearch o Neo4j (con una muy pulida extensin spatial),
aunque veremos si realmente sorprenden (www.elasticsearch.org). Personalmente
hoy en da pienso que los sistemas libres ms destacables para nuestro proposito son
PostGreSql, MySQL como gestor relacional, MongoDB como gestor no relacional NOSql
y SQLlite como gestor ligero relacional. Estos tres gestores relacionales permiten la
componente espacial. La decisin de usar estos u otros como SqlServer, DB2 u Oracle
(todos ellos sistemas propietarios con componente espacial), depende de muchos
factores, como por ejemplo que las plataformas de sistemas sean libres o no
(condicin para el uso de algunos tipos de software libre), costes totales de vida til
del sistema, confiabilidad etc.

Personalmente he podido testear (en SGBBDD libres) las componentes
espaciales de POSTGRE y SQLlite (MySQL tambin la tiene). Debo decir que POSTGIS
funciona a las mil maravillas y que Sqllite-Spatial aunque ralentizado con respecto al
anterior representa una excelente opcin para consultas no excesivamente
complicadas de cara a su inclusin en sistemas mviles o en trabajos de estudio en
donde el espacio sea un condicionante primordial. Por su parte SqlServer se ha
mostrado absolutamente eficaz en usos intensivos, lo cual en el caso de un
nomencltor resulta crucial. Veamos un ejemplo de cmo se realizara una sencilla
consulta sobre el nomencltor de CARTOCIUDAD (se trata de averiguar el nmero de
portales que se encuentran a 500 metros de la C/ Per n 25 de Coslada) en los dos
gestores GPL comentados en su versin espacial.

- POSTGIS



SELECT count(*) FROM PORTAL_PK T
WHERE ST_DWITHIN(
(SELECT K.THE_GEOM FROM PORTAL_PK K
WHERE K.ID_VIAL IN
( SELECT V.ID_VIAL FROM VIAL V
WHERE V.TIP_VIA LIKE 'CALLE%' AND V.NOM_VIA LIKE 'PERU%'
) AND K.NUM_POR = 25) , T.THE_GEOM,0.00926/2)

- SQLLITE SPATIAL

SELECT COUNT(*) FROM PORTAL_PK
WHERE CONTAINS (
(SELECT BUFFER (TRANSFORM(Geometry,25830), 500)
FROM PORTAL_PK WHERE ID_VIAL IN
( SELECT ID_VIAL FROM VIAL
WHERE TIP_VIA LIKE 'CALLE%' AND NOM_VIA LIKE 'PERU%'
) AND NUM_POR = 25.0)

NOTA.- Vase como en la consulta PostGIS se ha empleado un uso aproximado de equivalencia grados
metros (0.00926 <> 1000m), mientras que en SQllite-Spatial se ha preferido utilizar la transformacin
propia del gestor para la transformacin del SRID 4528 al 25830 (es decir el EPSG de ETRS89 geogrficas
a UTM).

Antes de continuar, resear que si los elementos geomtricos se almacenan
segn especificaciones OGC este tipo de consultas se pueden realizar de manera
cmoda mediante JTS (java topology suite) si usamos java o bien con NetTopologySuite
si usamos C#. Ambas son libreras absolutamente contrastada para realizar anlisis
espacial. Prueba de ello es el uso de JTS en el desarrollo de gVSig, que constituye el
proyecto SIG libre ms destacado de Espaa. Kosmo, evolucin del visor de jump
representa una excelente alternativa como visor, como servidor y como desktop de
dispositivos mviles (un proyecto que no hay que perder de vista tampoco).

Por ltimo me gustara destacar la importante decisin que deberemos tomar
sobre motores y gestores de servicios OGC cartogrficos. Aqu tambin surge la
dualidad, pero personalmente y teniendo en cuenta el propio espritu del nacimiento
de estos servicios, me decanto por software GPL MapServer, GeoServer, Deegree 2,


GeoNetwork (para metadatos)? En cuanto a Geoportales para interactuar con servicios
web son destacables Mapbender y OpenLayers.

Ejemplo de subrutina NATURAL en el entorno mainframe usado por el nomenclator BDC

Normalmente en geomtica nos vamos a encontrar con sistemas informticos,
contratos e imposiciones ya establecidos por parte de los departamentos de sistemas a
los que necesariamente habremos de adaptarnos. Esa es una realidad muy frecuente.


Si hay otra posibilidad se deber realizar un estudio profundo en base a los parmetros
ya comentados, con el fin de aprovechar la oportunidad de poder decidir entre
esquema propietario o libre y dentro de cada uno, evaluar el que ms se adapta a
nuestras caractersticas y sistemas optimizando su coste en trminos absolutos (el
coste de desarrollo, tambin lo es y adems de gran incidencia a largo plazo).

Ejemplo de salida de tareas de nomencltor en mainframe Z/Os (pantalla)- Fte IAM

La BDC, inicialmente nace como concepto de nomencltor propio, de la mano
de la entonces llamada Gerencia Municipal de Urbanismo en 1988. Al ao siguiente,
desde el tambin entonces llamado Centro Municipal de Informtica se ve la gran
utilidad que puede representar su uso y se comienzan a realizar dos estudios
diferenciados. Por una parte el uso cartogrfico a travs de dos plataformas, una
SICAD de Siemens bajo S.O. BS2000 y otra bajo ARCINFO bajo UNIX y en paralelo las


caractersticas alfanumricas del nomencltor propio desarrolladas bajo un mainframe
IBM 9021 modelo 821 (y 40 mquinas AS400). En aquel momento era inviable una
cohesin real de ambos sistemas, de manera que por un lado se realizaron estudios
SIG en el que se utilizaban lenguajes propietarios como AML para ArcInfo con el fin de
generar soluciones interesantes para el Ayuntamiento y por otro el esquema
alfanumrico, que fue el que realmente evolucin. As en el ao 1992 el sistema como
ayuda a la correcta integracin de informacin de calles en cada una de las
aplicaciones del CEMI se convierte en una realidad de mnimos. En aquel momento, las
aplicaciones tienen (cada una de ellas) su propio repositorio de direcciones y la BDC les
ayuda a que dicha informacin sea mejor. De este ao al 2001 aproximadamente se
acometen cuatro proyectos destacables, de los cuales perviviran dos de ellos (el
tercero fue el primer intento de aunar informacin cartogrfica y alfanumrica
[nomencltor geogrfico] gracias al uso de los PC como terminales, de manera que a
travs de un entorno cliente-servidor, e instalando como cliente DBR GIS, este permita
visualizar una GUI gestionada centralmente por Natural Geographic en el mainframe
mediante el producto de Software AG. (El proyecto, finalmente no prosper). Los tres
proyectos que llegaron a su fin por orden cronolgico fueron:

1. Desarrollo del sistema de direcciones no normalizadas y primeros callejeros de
la Comunidad de Madrid. Con ello las aplicaciones dejan de tener catlogos de
direcciones. Todo el nomencltor se encuentra descentralizado en BDC.
Normalmente se aprovechan migraciones de BBDD y reprogramaciones para
incorporar el nuevo sistema (UNISYS+COBOL -> DB2+NATURAL)
2. Se consigue un sistema eficaz de envo de informacin del nomencltor propio
desde la Gerencia de Urbanismo al Centro Municipal de Informtica. Hasta ese
momento las actualizaciones eran mensuales. A travs de Transparent Gateway
se consigue la conexin de Oracle-DB2 que posibilita el avance en la
actualizacin sobre el mainframe. (Hay otras opciones como EDITRAN de
INDRA)
3. Se implanta una copia mnima de BDC en DB2 bajo Windows que se actualiza
semanalmente para dar servicio a la gua urbana municipal y alguna aplicacin
que se genera en entornos cliente-servidor bajo windows.

Vemos que el continuo avance sobre distintos entornos han estado presentes
en la vida del nomencltor municipal, prcticamente desde su nacimiento. A partir del


ao 2003-2004 se acomete un ambicioso proyecto de cara a poder dar servicio a
aquellos aplicativos que vean necesario abrir la gestin a medios de tramitacin
multicanal. Es as como se acomete un nuevo anlisis, acogiendo la experiencia de
aos, para crear un nuevo diseo de BBDD ms eficiente y que permitiese al mismo
tiempo dotar a la BDC de una verdadera conexin geogrfica. No olvidemos que es en
ese periodo en el que se acomete el proyecto SIGMA (Sistema de informacin
geogrfica municipal), que nace desligado de BDC, lo que constituy a m entender uno
de los fallos de base de dicho SIG. Hoy se han subsanado algunos de los mismos y es
previsible que progresivamente se vaya corrigiendo este error de diseo. En un
principio se acometieron los desarrollos en java y Visual Basic bajo gestor DB2, que
luego migr a SqlServer 2000 y ms adelante a SqlServer 2005. En el ao 2006 la BDC
ya est implementada en el nuevo entorno para la primera aplicacin que migr (el
Padrn Municipal de Habitantes). En el periodo 2006-2010 se han acometido
importantes mejoras derivadas de la necesidad de disponer, no slo de toda la
funcionalidad del entorno mainframe, sino de nuevas surgidas a partir de las
oportunidades que brindaba el entorno, los nuevos diseos que permitan nuevas
preguntas y otras ms derivadas del fenmeno nuevas tecnologas. Los avances ms
destacables son en este periodo:

- Generar toda la funcionalidad mejorada en siete aos de cuanto se haba hecho
en dicisiete en el mainframe con un equipo realmente reducido.
- Generar nuevas funcionalidades y diseos derivados de las nuevas necesidades
y nuevo entorno.
- Invertir el flujo de actualizacin desde la BDC en entorno Windows al entorno
mainframe+AS400 y mejoras generales en la temporalidad y calidad de datos.
- Convertir BDC en suministrador de datos del SIG municipal (SIGMA). En la
actualidad ya muchos llaman a la BDC de Windows sistema BDC-SIGMA.
- Incorporacin de nomencltor estatal.

Un ejemplo de cmo los entornos usados condicionan funcionalidades es la
migracin de SqlServer 2000 a SqlServer 2005, que posibilit el cambio del flujo en la
alimentacin del nomencltor intrnseco desde el Departamento de cartografa de
Urbanismo. Efectivamente el nuevo SGBBDD incorporaba la posibilidad de realizar
conexiones calientes a otros gestores a travs de procesos almacenados de BBDD. As
era posible el traspaso controlado de la informacin en procesos nocturnos evitando


los elevados costes del producto mainframe. Un proceso de este tipo se basa en un
esquema similar al especificado a continuacin:

CREATE PROCEDURE

EXEC sp_addlinkedserver < servidor>,'Oracle', 'MSDAORA', 'conexion',
select * from Openquery (<servidor>, 'select * from table_de_ORACLE')
EXEC Sp_DropServer <>

END

El estado actual conlleva el mantenimiento de tres entornos diferenciados, lo
cual representa una complejidad mxima de diseo con el cual no ser habitual que en
geomtica nos enfrentemos, pero que en el Ayuntamiento de Madrid, por ser pionero
en este tipo de tecnologas nos hemos venido a encontrar.

Actualmente BDC se mantiene en los siguientes entornos:
1. Entorno MAINFRAME
- Sistema operativo Z/OS
- Lenguaje programacin Natural
- Gestor BBDD DB2
- Herramienta desarrollo Natural ISPF
2. Entorno DISTRIBUIDO
- Lenguaje programacin Java / VisualBasic
- Gestor BBDD SQLServer 2005
- Componente espacial SDE 9.3
- Arquitectura
o J2EE sobre Was 6.1
o Jdk 1.606 en procesos batch.
- Herramienta desarrollo IBM Racional Application Developer
(principal)



3. Entorno MVIL
- Lenguaje programacin Java
- Sistemas operativos Symbian y Android
- Herramienta desarrollo
o JavaME Platform SDK 3.0
o Eclipse SDK Android

En entornos mviles no hemos llegado a utilizar NDK r5 que nos hubiese
permitido programar en C#, lo cual es interesante, al haber NOKIA apostado por la
plataforma Microsoft, ya que as con el mismo lenguaje se puede abordar Android y
Windows mobile. Adems IOs utiliza Objetive-C, muy prximo a C#. Otras soluciones
que no hemos podido investigar son las herramientas abiertas MONO, PhoneGAP y
RubyMOTION.

En 2015 se prev que el 48% del mercado (mundial) est bajo dominio Android, mientras que Windows
mobile tendr una cuota de 20% e iOS del 17%. Depender en gran medida de la decisin de los
fabricantes ya que el hecho de haber comprado Motorola (2011) no ha gustado mucho en el sector de
los fabricantes. En cualquier caso hay que contar con los tres S.O. y creo que la evolucin de Microsoft
ser algo ms positiva y menos la de Android en la proyeccin 2015 y a nivel mundial, mientras que en
Espaa si es posible que incluso se superen dichos porcentajes a favor de Android en el mercado de los
smartphones. Fte: Bitelia



Esquema de la distribucin y servicios de BDC en el Ayuntamiento de Madrid. El mantenimiento de
sistemas en paralelo representa un reto en cuanto a la homogeneidad de informacin.

Hemos intentado con el presente punto hacer ver la complicacin y necesaria
formacin en diferentes entornos imprescindible para poder abordar con garantas de
xito un nomencltor en el mbito de una gran AALL. Evidentemente la geomtica
comprende un riguroso y profundo conocimiento tanto de topografa como de
informtica, destacando adems dentro de esta ltima la concreta especializacin en
lenguajes y tecnologas propias con profesionales que actualmente cuesta encontrar
en el mercado laboral.

En el mbito del Ayuntamiento de Madrid el problema principal consiste en que
la coordinacin de un sistema homogneo desplegado en tantos entornos y
alimentado en diversos flujos representa un quebradero de cabeza continuo para el
mantenimiento estable de la informacin. Es una de esas tareas fundamentales que al
mismo tiempo se convierten en transparentes para los dems, pero sin las cuales el
sistema sera un fracaso. Siempre he dicho que el mayor xito de un nomencltor


dentro de una AALL es que nadie hable de l. Esa es la mejor seal de que se est
realizando un gran trabajo.

TECNOLOGAS DISPONIBLES. DECISIN

Ya hemos visto en los apartados anteriores algunos de los problemas bsicos a
los que nos enfrentamos a la hora de abordar este tipo de proyectos. En este apartado
pretendemos dar a conocer decisiones en el caso concreto del proyecto BDC,
centrndonos fundamentalmente, aunque no nicamente en el entorno distribuido
del nomencltor del Ayuntamiento de Madrid.

LA DECISION ACERTADA Y OTRAS TCNICAS DE DISEO

Bsicamente un proyecto geomtico parte como cualquier aplicacin
informtica del estudio de un anlisis funcional y otro de requisitos. Aunque parezca
trivial, lo primero que debemos preguntarnos es si lo que tenemos que realizar es
realmente necesario o existen alternativas de reutilizacin de otros desarrollos
previos. Un analista debe tener la caracterstica de saber dar las vueltas suficientes a
un determinado problema como para estar seguro de que el nacimiento de un nuevo
diseo es inevitable. Tambin se debe de ser riguroso a la hora en la que se nos piden
nuevas funcionalidades, ya que el nomencltor es y debe ser un servicio genrico en el
que las particularidades son de los aplicativos que lo usan, debiendo nicamente
representar ste el modelo de datos til para la generalidad. Una tercera caracterstica
de los nomencltor respecto a otro tipo de desarrollos es que en este caso es
aconsejable adelantarse a las necesidades del usuario por dos causas principales, la
primera debido a que nunca un nomencltor, como servicio central que es, debe
representar una rmora en plazos para los aplicativos que tienen dependencia de l, y
segundo que normalmente, dadas las tecnologas usadas en el mismo, los proyectos
informticos no suelen ser conscientes de posibilidades de respuesta que podemos dar
desde nuestro nomencltor, por lo que para ellos muchas veces esa nueva
funcionalidad representa ideas que nunca hubiesen considerado (al menos de ese
modo) en el desarrollo de sus propios aplicativos.


Existe la necesidad? Esta es la primera pregunta que se debe responder
cuando alguien nos plantee el desarrollo de un nomencltor. No podemos olvidar los
distintos proyectos llevados a cabo, como Nomecalles, Cartociudad, Eiel, Catastro etc.
Son proyectos que pueden cubrir las necesidades requeridas con un esfuerzo de
integracin muy inferior al necesario para un desarrollo integral. Esa ser una decisin
fundamental, basada en tres factores fundamentalmente:

- El sistema precisa un desacoplamiento total de ubicaciones por parte de los
aplicativos a los que servir?
- Se podrn georreferenciar todos los datos que lo requieren?
- Tenemos todos los datos disponibles o en su caso la actualizacin de los
mismos es suficiente para nuestros propsitos?
- Es posible que el sistema remoto de nomencltor sea desactivado en algn
momento? Qu horarios son factibles? Es este horario compatible con el de
la Organizacin que facilita el servicio de nomencltor?

En el Ayuntamiento de Madrid se precisa de un sistema en el que ningn
aplicativo almacene informacin sobre ubicaciones geogrficas (sistema ms avanzado
de nomencltor), por lo que lgicamente la necesidad de su existencia es inmediata.
Adems de esto lo sera por los niveles de actualizacin, datos no disponibles y la
existencia de los servicios 24 horas a los que hay que suministrar informacin
actualizada diariamente.

En el anlisis funcional bsicamente se establece un catlogo de requisitos y
una descripcin de las respuestas a dichos requisitos fundamentada en una
descripcin del sistema que deber de analizar casos de uso y secuencias a travs,
normalmente de los correspondientes diagramas. En esta fase destacaremos los
siguientes pasos:



Bsicamente las tareas que realizaremos en cada una de las fases sern:

1. Fundamentalmente en este tem se realiza una descripcin del sistema
deseado, delimitando su alcance (inferior y superior) y se establecen las
relaciones con otros sistemas, identificando usuarios representativos para
poderles entrevistar y lograr una correcta identificacin posterior de requisitos.
Adems se resean documentos de obligado cumplimiento o que habr que
considerar en la redaccin del anlisis.

Modelo lgico (comn) de un posible sistema del nomencltor.


El modelo fsico del modelo lgico slo se diferencia en que en el
modelo fsico especificaremos fsicamente el soporte. Por ejemplo en el modelo
fsico podramos especificar lo siguiente:

- Servidor web: Especificaremos si es un Apache Tomcat o un Internet
Information Server y a estos servidores web, adems puede ser
necesario aadir un Geoserver, un Mapserver, un ArcIMS etc, como
servidores de mapas.
- Servidor de aplicaciones: En el caso de BDC ser WebSphere (Java EE),
pero podra ser Weblogic, EAServer (O en GPL Jonas, JBoss o Gernimo)
o tambin Internet Information Server (NET con C# por ejemplo) (O en
GPL Zope, Base4). Tambin podr ser necesario un servidor de
aplicaciones GIS especfico.
- Servidor de BBDD: Especificaremos si se trata de SqlServer y la
extensin de datos espaciales o sistema propietario (ArcSDE en el caso
de Madrid).

Es importante que pongamos el S.O soporte de cada servidor y todas las
versiones que se van a utilizar. Tngase en cuenta que los cambios de versiones
a veces suponen un coste especfico importante (Por ejemplo los DTS [Data
Transformation Service] de SqlServer 2000 se pudieron recompilar en 2005,
pero se perda la capacidad de edicin (cdigo fuente no modificable), lo que
de hecho supona rehacer todos los DTS que tuviese una aplicacin. En BDC a
partir de ese momento prohibimos la realizacin de nuevos DTS y acometimos
la transformacin de los que tenamos en programas). Vemos pues que los
costes que puede suponer un cambio de versin son importantes. La versin
firmada en el anlisis es la establecida.

2. Esta fase supone el establecimiento de reuniones y transcripcin a texto para la
validacin por parte del usuario de aquello que quiere que haga el sistema. Al
final de todas ellas deberemos de ser capaces de tener claro el catlogo de


requisitos. Dichos requisitos ser fundamentales, pues los resultados obtenidos
en la modelizacin posterior debern responder exactamente a ellos.

Esta fase es de gran trascendencia, ya que muchas veces el usuario no sabe
expresar y en otras el analista no sabe entender aquello que se le explica (algo
obvio para el usuario no lo es para el analista). En general un nomencltor da
servicios no slo tcnicos en el mbito geomtico, de manera que habr que estar
seguro de haber entendido correctamente lo que se desea de nuestro sistema. En
cualquier caso se deben especificar los siguientes criterios:

- Facilidades que tiene que proporcionar el sistema.
- Restricciones a las que estar sometido en cuanto a rendimiento.
- Restricciones en cuanto a la frecuencia de tratamiento.
- Criterios de seguridad.
- Controles de acceso.

La definicin de cada requisito adems llevar aparejada la siguiente catalogacin:

- Tipo de requisito.

Funcional: Se entiende por requisito funcional, todo requisito que debe
ser capaz de realizar el sistema, sin considerar restricciones fsicas,
tambin, entran en esta catalogacin, los requisitos que especifican el
comportamiento de entrada/salida.

No funcional: Los requisitos no funcionales, comprenden todos aquellos
que especifican propiedades del sistema, como restricciones del
entorno o de implementacin, rendimiento, dependencias de la


plataforma, mantenibilidad, extensibilidad o fiabilidad. Tambin se
incluyen como requisitos no funcionales, los que se refieren a las
restricciones fsicas sobre un requisito funcional. Entre estos tipos de
requisitos se pude distinguir:

- Servicio.
- Rendimiento.
- Seguridad.
- Implantacin.
- Disponibilidad del Sistema.

- Estado.
Propuesto.
Aprobado.
Incorporado.

- Prioridad.
Alta.
Media.
Baja.

Vamos a ver a continuacin una serie de requisitos y el modo de presentarlos
(ejemplo entre otras muchas de las posibles formas de exponerlos). Ver pgina
siguiente

3. En esta fase desgranaremos la composicin de la informacin, agrupndola en
su caso (como suele ser) en un conjunto de subsistemas que controlen datos
y/o tareas.



Identificador del Requisito RQN-01 REQ_FUNC_NOMEN
Nombre Devolucin de coordenadas ETRS89
Origen Organismo peticionario (que proceda) NOMENCLATOR
Tipo de Requisito Funcional
Requisitos Relacionados
Descripcin
Se debe retornar mediante campos especficos (nombres
de campos nicos en la aplicacin llamante)
coordenadas geogrficas de la posicin guardada. Esta
funcionalidad debe de estar incluida en la opcin de
georreferenciacin del nomencltor de intranet.

Prioridad Alta Estado Aprobado
Fecha Creacin 31/01/2013 Fecha Revisin

Identificador del Requisito RQN-02 REQ_FUNC_NOMEN
Nombre Carga inicial de tabla de rotulacin de vas.
Origen Organismo peticionario (que proceda) NOMENCLATOR
Tipo de Requisito Servicio
Requisitos Relacionados
Descripcin
Previa a la entrada en explotacin del aplicativo, deber
de realizarse la carga inicial de rotulaciones previa
parada del servicio previo que realizaba la transferencia
semanal de dicha informacin, de manera que se
imposible la perdida de datos.

Prioridad Alta Estado Aprobado
Fecha Creacin 31/01/2013 Fecha Revisin



Suele ser habitual en esta fase realizar un primer diagrama de subsistemas, en
el que se especifiquen agrupados en subsistemas (mdulos) el conjunto de requisitos
funcionales (por ejemplo el requisito funcional RQN-01 visto antes podra estar en un
mdulo de solicitudes espaciales). Tambin se especifican en l las dependencias entre
mdulos si las hubiera.

Un segundo diagrama que es aconsejable realizar es el de casos de contexto de
subsistemas en el que queden identificados como actores todos aquellos elementos
fundamentales que interactuarn con cada uno de los subsistemas (usuario internet,
usuario intranet, Administracin del nomencltor, cliente pesado (ArcGIS), cliente
ligero (Internet Explorer, etc.)

Ejemplo de casos de contexto de subsistemas. Ntese la herencia entre el mdulo de validacin de
direcciones web con respecto a la del mdulo de validacin de direcciones (En UML se denomina
generalizacin). En general tendremos tres asociaciones bsicas, la de generalizacin ya comentada y
otras dos ms de asociacin convencional (todas las del ejemplo) o asociacin de dependencia (se
representa igual que la anterior, pero con la lnea a rayas)



Por cada mdulo se realiza un diagrama con los distintos casos de uso de dicho
mdulo (se correspondern en gran medida al agrupamiento hecho en requisitos, pero
pueden aparecer nuevos). En este aparecern los actores implicados con respecto al
mdulo, un mdulo central del que saldrn todos los casos de uso.

Ejemplo de diagrama de clases asociadas a un mdulo (subsistema)

4. A partir del concepto objeto determinaremos las clases del mismo y el
comportamiento de la misma para resolver cada uno de los casos de uso que
afecten a dicho objeto.



Despus realizaremos el estudio de cada caso de uso, de manera que es
aconsejable primero realizar un estadillo de la informacin de la clase y luego
realizar el diagrama de secuencia, puesto que es muy legible de cara al usuario
tambin. En el ejemplo realizaremos una simulacin de cmo podra ser una
clase del nomencltor que realiza una peticin a travs de la intranet para
obtener un informe de una direccin en formato PDF (Se puede profundizar
sobre las tcnicas de modelado UML [Unified Modeling Language] en
www.uml.org).

Caso de Uso: Envo de Plano PDF
Versin: 1.0
Identificador: CUxxx 1
Tipo: Principal
Actores: Usuario Internet
Precondiciones: Abrir Aplicacin numeracin
Solicitar el envi del plano en formato PDF
Postcondiciones: Obtener un fichero PDF, va e-mail, de los datos de
la direccin solicitada
Excepciones:
Descripcin:

El usuario, a travs de la aplicacin numeracin, realiza la peticin de
envo de informacin en formato PDF.

El usuario introducir el nombre y e-mail.

Caminos Alternativos:

Requisitos: REQ_FUNC_xxxx



Ejemplo de presentacin de un caso de uso de un subsistema (estadillo y diagrma de secuencia)

5. Es el diseo de las pruebas necesarias para garantizar que el punto 4 (sistema
diseado) cumple el punto 2 (sistema idealizado por el usuario)

El plan de pruebas suele definirse con tres apartados, pruebas unitarias o
relativas al correcto funcionamiento de lo desarrollado (se suelen ir realizando,
segn terminan los desarrollos de casos de uso), pruebas de integracin, que
consisten en comprobar que cada uno de los subsistemas interacta
correctamente (se realizan al concluir el desarrollo completo de la aplicacin),
pruebas del sistema, que suman a las anteriores pruebas la posible y correcta


interaccin de nuestro sistema si tienen interrelacin con otros sistemas o
aplicativos y por ltimo las pruebas de integracin, que consisten en implantar
el aplicativo en el entorno de explotacin, de manera que todos los requisitos
no funcionales hayan sido tenidos en cuenta.
En general, las pruebas que realizaremos directamente y sin coordinacin con
otros equipos sern los tres primeros. Es interesante que cada probador utilice
impresos al efecto con cierto grado de normalizacin para poder ser validados
en caso de algn problema.

PRUEBA UNITARIA DE APLICACIN
Nombre de la clase Identificacin

Especificacin aplicable Referencia

Lista de pruebas Requisitos que prueba
Id. Nombre Tipo

Ejemplo de estadillo normalizado para analistas-programadores del nomencltor.

Es importante destacar aqu que una de las pruebas que no debemos de
obviar nunca es la prueba de carga y estrs del sistema. Las pruebas de estrs
consisten en crear momentos crticos de peticiones que nos puedan alertar
sobre cuellos de botella cuyas causas pueden ser de muy distinta naturaleza
(diseo, programacin, bloqueos BBDD, etc.). Para este fin se utilizan
herramientas especficas como Microsoft Web Application Stress Tool, Apache
JMeter, Mercury LoadRunner, Radview WebLOAD y en GPL tenemos JCrawler.



6. Aprobacin del anlisis. Suele consistir en la firma de la aceptacin por parte
del cliente. En nuestro caso, al no tratarse de una tarea externa este paso se
obvia puesto que cliente y redactor coinciden.

Diremos que el objeto de este apartado, no es lgicamente presentar todo el
diseo de un sistema completo, sino proporcionar las herramientas y conocimientos
necesarios para hacerlo, de manera que las tcnicas de modelado se escapan del
alcance de este estudio al entender que deben de ser conocidas, al menos
sucintamente. UML es un lenguaje de modelado de propsito general, en torno al cual
se han ido definiendo determinadas tcnicas que ayudan a poder realizar un anlisis
riguroso ordenadamente. En el ao 2000 fue aceptado dentro de la International
Organization for Standardization (ISO), desde entonces se ha convertido en un
elemento bsico y as hoy todos los documentos tcnicos sobre OGC y cualquier
aplicativo de nomencltor los vamos a encontrar en este lenguaje de modelado. Por lo
tanto su conocimiento se hace imprescindible dentro de la geomtica y lgicamente
formar parte de su curriculo.

Por ltimo decir que toda tcnica es correcta, que es aconsejable utilizar para
ello UML, pero no imprescindible y que lo importante es que el diseo que se idee nos
lleve a la decisin correcta. Ya decimos que existen otros caminos para llegar a ella, sin
embargo UML adems est orientado a la generacin de clases en las que se basan los
lenguajes ms utilizados en entornos distribuidos (java, C#, Python...) por lo que no
slo estaremos realizando un modelado adecuado, sino que estaremos generando (si
llegamos a los ltimos estadios de modelacin) las clases y sus relaciones en la propia
herramienta de programacin. El IBM Rational Application Developer V6.0, por
ejemplo, ya lo contempla.

DECISIN DE BASE DE DATOS

En el Ayuntamiento de Madrid y en los primeros tiempos informticos se
utilizaban frecuentemente los ficheros indexados (VSAM) que permitan avanzar a
posiciones exactas. Como formatos para compartirlos entre mquinas se usaron el NFS


y ms tarde el RAID. Despus aparecieron las BBDD jerrquicas en las que los datos
deben de ser jerrquicamente ordenados y recorridos (muchas entidades bancarias
siguen usando este modelo, pues se adapta muy bien a su negocio), pero en
Informtica Ayuntamiento de Madrid, la primera BDC nace ya en una base de datos
relacional (RDBMS).

Las BBDD relacionales trajeron consigo el SQL (Standard Query Language) y las
denominadas propiedades ACID. A saber:

- Atomicidad: Una transaccin de usuario se trata atmicamente. O se ejecuta
todo o no se ejecuta nada.
- Consistencia: Una transaccin cumplir las restricciones definidas dentro la
BBDD. Si no lo logra no habr ejecucin, quedando as la coherencia e
integridad de datos preservada totalmente.
- Aislamiento: El resultado de una transaccin no es accesible a otra transaccin
hasta que aquella no termina.
- Durabilidad: Terminada una transaccin, sus resultados son permanentes y
sobrevivirn a cadas de la BBDD y/o del sistema soporte

Aqu trataremos las BBDD relacionales que hoy por hoy son las que nos vamos a
encontrar en la gran mayora de los casos. Ya vimos anteriormente que estn
surgiendo nuevos gestores no totalmente basados en el modelo relacional que hay
que vigilar, pero salvados los tiempos de las BBDD jerrquicas, podemos decir que hoy
por hoy el mundo de las BBDD es relacional. Eso si analizaremos separadamente las
alfanumricas de las espaciales, de manera que en funcin de las necesidades
concretas o condicionadas a nico paquete podamos tener una idea de por dnde nos
interesa realizar el estudio concreto. Se pretende aqu dar unos mnimos para eso,
para poder realizar una prueba no sobre todas las BBDD disponibles, sino hacerlo
sobre aquellas que hayan pasado un filtro de nuestros requerimientos ms
importantes. Para ello daremos algunas nociones sobre las caractersticas de algunas
de ellas.



El gran auge y xito de las RDBMS por parte de los usuarios informticos ha
hecho que surjan multitud de gestores diferentes tanto GPL como propietarios. Un
gestor posibilita el uso de una RDBMS de forma sencilla tanto el desarrollo (API) como
la gestin de los datos que contiene la BBDD. Veamos algunas de las ms utilizadas:

MySQL
La ltima versin con la que personalmente he trabajado ha sido la 3. Aunque
es multiplataforma se suele ver siempre bajo LINUX. Es muy sencilla de instalar y
gestionar. Su expansin viene ligada a la aparicin del lenguaje PHP para web.
Lamentablemente no cumple con algunos criterios ACID, lo cual para una BBDD es
esencial (Carece o al menos careca de triggers, procedimientos almacenados y
dispona de una pauprrima integridad referencial). Actualmente puede que algunas
de estas caractersticas hayan sido mejoradas pues la versin actual es la 5.6. Una
ventaja es que admite datos espaciales. (http://dev.mysql.com/doc/refman/5.0/en/creating-a-
spatially-enabled-mysql-database.html). Personalmente creo que puede ser una herramienta
interesante para pequeos desarrollos autnomos, pero no es una alternativa a la hora
de poner en riesgo la efectividad de una gran corporacin. Es GPL y para m, aunque
disponga de alguna capacidad superior se encontrara en comparativas de gestores de
niveles inferiores como ACCESS.

SQLServer
He trabajado con l hasta la versin 2005. No es multiplataforma, pero trabaja
sobre cualquier sistema Windows, sea el que sea. Queda automticamente descartada
si deseamos trabajar sobre sistemas GPL, pero si lo vamos a hacer sobre servidores
Windows es ms que recomendable. Su instalacin y mantenimiento es sumamente
sencillo para los equipos de administracin y admite todos los protocolos de red de
uso comn, admitiendo tecnologa cliente-servidor. La escalabilidad del producto es
total y sus caractersticas tcnicas excelentes: Soporte de transacciones OLPT, mquina
de bsqueda de textos completos que permite localizar informacin a lo largo de todos
los campos de una tabla, bloqueos dinmicos a nivel de filas, optimizacin de consultas
(algunos planes de acceso de consultas son demasiado listos y crean problemas de
programacin), estadsticas automticas, replicaciones de BBDD dinmica y muchsimo
ms. Su gran ventaja es la estabilidad y seguridad de datos y como desventaja


podramos hablar de un consumo elevado de recursos de mquina. Por supuesto
admite datos espaciales: (http://msdn.microsoft.com/en-us/library/bb933876(v=sql.105).aspx).

Tier Features Sample Products Price
Free - Limited database functionality
- Memory limits, database size
limits, functionality limits
- SQL Server Express Edition
- Oracle Express Edition
- DB2 Express-C Edition
FREE
Basic - Basic database functionality
- Simplified management tools
- Basic security
- CPU and memory limits
- Microsoft SQL Server
Workgroup Edition
- Oracle Standard Edition One
- DB2 Express Edition
$3,500$6,000
per CPU or per Core
Standard - Basic high availability
- Full database functionality
- Basic management tools
- CPU and memory limits
Standard Edition
- Oracle Standard Edition
- DB2 Workgroup Edition
$7,000$18,000
per CPU or per Core
Enterprise/
Data Center
- Premium high availability
- Scalability
- High-end management tools
- Enterprise security
- No CPU and memory limit
Enterprise Edition and Data
Center Edition
- Oracle Enterprise Edition
- DB2 Enterprise Edition
$27,000$55,000
per CPU or per Core
Documento de SQLSERVER 2008/R2 - Do Not Pay Too Much for Your Database Licenses
Fte: Microsoft Corporation

Se trata de una excelente opcin con la cual no he tenido prcticamente ningn
problema. Para aprender su manejo y gestin, Microsoft permite su descarga
operativa completa (express) http://www.microsoft.com/es-es/download/details.aspx?id=29062 .
No es GPL y va desde los 3649 hasta los 41630 (cambio aproximado a 26/03/2012)

ORACLE
Oracle es la base de datos relacional propietaria por antonomasia. He trabajado
con ella en la versin 8. Es una RDBMS multiplataforma (menos en la versin gratuita)
que podr correr sobre Windows, Unix y otros sistemas 64 bits. Tambin admite
prcticamente todos los protocolos de red al uso. Para establecer una comparativa


entre versiones y ver sus altas capacidades recurriremos a la siguiente tabla (se trata
de la versin 12 enfocada a pequeas y medianas empresas):

http://www.oracle.com/us/products/database/enterprise-edition/comparisons/index.html

Se trata de un gestor de inigualables prestaciones y en ese sentido no tiene
nada que envidiar a SqlServer. Entramos en un terreno complicado al comparar a estos
dos gestores. Lo primero en lo que hay que pensar es el si algn da nuestras
plataformas dejarn de ser Windows. En ese caso ya tenemos un punto a favor de
Oracle, que disea sus motores en funcin de los ms de 80 sistemas (incluidos
sistemas Apple) sobre los que puede correr, aprovechando las caractersticas del
mismo, cosa que SqlServer sabe hacer mejor que nadie para Windows. La versin 10
de Oracle ya automatiza como SqlServer las tareas administrativas lo cual ha quitado
ese punto de beneficio a SqlServer y ambos poseen un sistema grfico de
administracin permitiendo comandos DDL y DML, pero SqlServer usa tecnologa
Always-on que supone unos tiempos de parada de BBDD realmente bajos. Tambin en
contra ms que a favor de SqlServer podemos decir que la NIST (National Vulnerability
Database de EEUU) ha informado (segn su competidor) de 330 fallos de seguridad
(personalmente me parecen excesivos) en Oracle frente a los 25 de SqlServer. Es
interesante el realizar consultas en este organismo porque no slo detecta fallos, sino
que da pistas o directamente recomienda como resolverlos
(http://web.nvd.nist.gov/view/ncp/repository ). En contra de Oracle podemos decir que tiene
demasiados productos extras an en versiones de gama alta y precio superior.

Oracle ha sacado una versin ligera llamada 11 para pequeas y medianas
empresas a un coste realmente competitivo (164) que puede ser muy interesante.
Por supuesto Oracle tiene capacidad espacial siendo uno de los pioneros en este
sentido, lo que le avala sobradamente.

En contra de SqlServer por ltimo podemos decir que el lenguaje de
procedimientos almacenados de Oracle PL-SQL es ms potente que el de SqlServer T-
SQL.


DB2
DB2 es una plataforma de precio similar a Oracle con el que prcticamente se
mide en paralelo. Hasta en el sistema Z/Os de IBM un Oracle puede correr, de manera
que para ambos competidores no hay prcticamente limitacin de plataformas, pues
DB2 tambin puede correr en plataformas GPL como Linux y en propietarias como
Windows. La escalabilidad de DB2 es impresionante pues puede ir desde un simple
ordenador hasta el ms complejo de los sistemas.

Algo importante de resear es que desde la versin 9, ya no slo hay
capacidades espaciales en Unix, Linux y Windows, sino tambin en Z/OS (http://www-
01.ibm.com/software/data/spatial/db2zos/ ).

DB2 es una de las BBDD ms vendidas del mundo, que como sus competidores
dispone de una versin libre denominada DB2 Express-C y aunque se trata de un
gestor muy ligado a los productos IBM, no deja de ser una excelente herramienta,
confiable y eficiente que se debe de tener en cuenta a la hora de decidirnos por un
gestor. Entendemos al mismo tiempo que el hecho de disponer de la experiencia de la
adquirida Informix hace de IBM siempre un valor seguro.

He usado DB2 en entornos Z/Os y Windows y no he tenido quejas en su uso.
Slo en z/Os he podido probarlo con una carga significativa de datos.

POSTGRESQL
PostGREsql tiene la ventaja en principio de ser GPL y ser mucho ms robusto
que MySQL. Es capaz de correr sobre Windows, por lo que representa un competidor
tambin para SqlServer. Por el contrario es incapaz, como tambin lo es SqlServer y
Mysql de correr bajo Z/OS y Unix. Las capacidades del gestor son completamente
profesionales, salvo que no admite consultas paralelas y no admite vistas


materializadas. Cumple totalmente las caractersticas ACID y sus ms de 15 aos de
desarrollo lo avalan. En el caso de su versin espacial llamada POSTGIS he podido
comprobar su rendimiento equiparable totalmente al que pueda realizar la versin
espacial de ORACLE por poner un ejemplo. Como desventaja, aadiendo que es tpico
de los buenos sistemas es un gran consumidor de recursos de mquina.

Ellos aseguran tener mejor soporte que muchos fabricantes de BBDD
propietarias, aunque no lo sabemos realmente. Es cierto, sin embargo, que es tal vez la
nica BBDD GPL en la que confian empresas de la talla de la alemana BASF, El Servicio
postal de EEUU o bien el INEGI (Instituto Nacional de Estadstica y Geografa e
Informtica de Mjico en el cual he tenido la suerte de impartir algn curso de cara a la
formacin de ingenieros y personal tcnico del programa PROCEDE).

Aunque he intentado plasmar en este apartado los principales gestores, existen
otros muchos. Tan slo me gustara resear que he utilizado el SQLlite spatial versin y
aunque se trata de un gestor menor puede ser muy til de cara a dispositivos mviles
por su mnimo tamao. En realidad la decisin del gestor a usar en una corporacin
como puede ser el Ayuntamiento de Madrid no va a depender tanto de uno u otro
aplicativo (de los que considerarn sus necesidades) sino de una decisin corporativa.
En la actualidad en el Ayuntamiento de Madrid se usan gestores de DB2, Oracle y
SqlSERVER de forma principal. Personalmente creo en la alta potencialidad de PostGRE
y PostGIS como base de desarrollo de nomencltores, no obstante el problema de
migraciones SQL entre BBDDEE (JDBC o Hibernate ya lo hacen en las BBDD
alfanumricas) hoy en da es un verdadero problema debido a la diferencia de sintaxis
entre gestores. Esto queda resuelto usando un gestor espacial externo como SDE, con
lo que la migracin en el aspecto espacial quedar resuelto, pero habremos incluido un
coste a nuestro sistema. Como siempre la decisin depender de un cmulo de
parmetros que ponderado adecuadamente nos llevar a una decisin correcta, entre
los que en primer lugar consideraremos que el sistema cumpla con las especificaciones
tcnicas que tengamos (datos y operaciones sobre ella), capacidades de herramientas
CASE, interaccin con lenguajes a utilizar, capacidades tcnicas de integridad, claves
forneas, recuperacin de datos, creacin de ndices, controles de acceso, seguridad
general, consumo de recursos y herramientas de monitorizacin, estrs y un largo etc.



Estudio de Forrester de 2009 sobre el mercado actual de los gestores de BBDD

DECISIN DE LENGUAJES

Evidentemente cualquier plataforma ya de por si nos est condicionando el
lenguaje y viceversa, por lo que si nos es posible (no viene impuesto por alguna otra
razn) el estudio de aquello que queremos realizar deber representar siempre el
menor coste posible. A lo largo de mi vida profesional he tenido que aprender multitud
de lenguajes de programacin (Basic, Pascal, Visual Basic, AML, OPL, Cobol, RPG,
NATURAL, java y C#) y lenguajes de proceso por lotes (BAT y JCL) pero siempre hay
uno o dos de ellos en los que nos sentimos realmente cmodos. El esfuerzo que
requiere el control real de un lenguaje de programacin tiene una curva de
aprendizaje elevada por lo que es importante tener en cuenta los siguientes aspectos:


- Lenguajes en los que nos sentimos muy cmodos.
- Plataforma necesaria para minimizar costes de desarrollo y despliegue.
- Base de datos idnea y compatibilidad con plataforma.
- Condicionantes externos impuestos

Imaginemos como ejemplo que si nos interesa como soporte espacial de
nuestro nomencltor un producto GIS como el de ESRI tendremos dificultades
eligiendo como lenguaje C# a la hora de desarrollar sobre Android y si usamos java lo
tendremos para desarrollar sobre mviles de Apple o que lleven Windows phone o su
antecesor Windows mobile. Si vamos a desarrollar sobre Linux no nos quedar ms
remedio que usar java y que si queremos desarrollar en C# no nos quedar ms
remedio que usar plataformas propietarias de Windows. En otro orden de cosas si
vamos a utilizar software GPL (el mal llamado software libre) normalmente estos para
uso comercial tienen limitaciones especficas, unos incluso en plataformas Linux y
otros en plataformas Windows.

La decisin no es trivial. En cualquier caso pretendemos hacer ver que de ella
depende mucho la eficacia de nuestro sistema y los costes de desarrollo. Por otro lado
si en SQL encontramos caractersticas especficas de cada gestor, en SQL-spatial lo que
nos vamos a encontrar es muchos SQLs diferentes bajo un aspecto parecido. Con esto
quiero decir que en el uso espacial de las BBDD es importante tambin el
conocimiento del SQL especfico a usar o del SDK correspondiente a la plataforma (SDK
[Software Development Kit] es el nombre que suelen recibir las API mviles). Sistemas
como el de ESRI no condicionan este aspecto a travs del uso de SDE (conexin
multiplataforma de gestor), sin embargo el sistema ESRI es propietario y estar
condicionando el gestor y adems dicho gestor se ver condicionado por la plataforma
o sistema operativo del servidor en el que se instale.



Lenguajes de programacin y S.O. con capacidad de desarrollo de uso de libreras ESRI para dispositivos
mviles Fte ESRI Espaa.

Hoy en da la mayora de desarrollos se estn realizando sobre plataformas
distribuidas (redes de servidores) por lo que en principio un valor seguro siempre lo
darn los lenguajes java o C# (El poder de desarrollo que da la conjuncin de ambos
lenguajes es total hoy en da sobre un proyecto geomtico). Estos lenguajes debern
de ser conocidos en mayor o menor medida para cualquier profesional que quiera
desarrollar aplicaciones de nomencltor. As mismo se requerir un conocimiento de
SQL estndar y manejo de al menos algn SQL-spatial.



En el caso que nos ocupa del nomencltor municipal el sistema est
condicionado por las herramientas corporativas oficiales. En nuestro caso el
nomencltor del mainframe se mantiene mediante el uso del lenguaje NATURAL sobre
SQL de DB2. En los sistema AS400 para el manejo del nomencltor se usa RPG y para
los sistemas distribuidos hemos utilizado java y en menor medida VisualBasic con SQL
de SqlServer 2000/2005 y plataforma espacial SDE, pero debemos decir que todo ello
ha venido condicionado siempre desde instancias superiores en el que ningn peso ha
tenido el hecho de determinadas necesidades que pudiera tener el nomencltor
municipal (debe tenerse en cuenta que el nomencltor es una parte de Informtica
Ayuntamiento de Madrid y una cierta homogeneidad es esencial y en ese sentido
tambin hay que saber adaptarse a las circunstancias). Podemos decir, por ejemplo
que la decisin sobre modificaciones de gestores de BBDD siempre ha sido impuesta,
de manera que se nos dan fechas lmites para las migraciones (En el entorno
distribuido se ha migrado desde DB2 a SqlServer 2000 y desde este a SqlServer 2005).

De todo lo expuesto anteriormente podemos extraer tres conclusiones bsicas

1. Conviene tener muy claras las caractersticas de un determinado desarrollo
para elegir el lenguaje y plataforma que cumpliendo su fin minimice el coste del
producto.

2. Es necesario que un equipo de desarrollo geomtico sea capaz de adaptarse a
cualquier entorno o cambio en cuanto a gestores de BBDD y lenguajes.

3. Hoy en da es muy aconsejable el dominio de los lenguajes java y C# en
cualquier proyecto de caractersticas espaciales.



Plataformas y lenguajes utilizados en el nomencltor municipal de Madrid

BASE LGICA FUNDAMENTAL DEL NOMEN-
CLTOR

Para una gran organizacin el nomencltor no slo debe de contemplar, como
ya se apunt, el conjunto de direcciones y ubicaciones sean toponmicas, de inters u
otras. Debe de contemplar un sistema capaz de almacenar y en su caso mejorar y
servir de entorno centralizado de todo elemento que quiera interactuar con l. Esta
puntualizacin no dejamos de insistir que es lo que hace a un nomencltor ser un


nomencltor adecuado a su concepcin moderna. Si se quiere a los nomencltores
propios, metropolitanos y estatales se le podra aadir esta caracterstica aadindole
el nomencltor no normalizado, es decir el de aquellas direcciones a las que no se ha
podido dar respuesta total o parcial, pero que se integran como parte del mismo.

As un nomencltor de una gran AALL no se debe de conformar con ayudar,
sino que debe de gestionar la totalidad de direcciones del municipio, siendo el
responsable de poner los medios para su correcta incorporacin, celo en su custodia y
mejora y dar respuesta eficiente a cuantos procesos se deriven de esa unicidad o
centralizacin de la informacin. El hecho de establecer un sistema de nomencltor
como el propuesto implica la gran responsabilidad de ser bsico para el correcto
funcionamiento de toda aquella aplicacin que confe en l. Pensemos en una emisin
de un tributo municipal, en la remesa del envo de multas de circulacin o el envo al
INE del Padrn para hacernos una idea del alcance de lo que un mal diseo del
nomencltor municipal puede ocasionar.

Partiremos de una idea abstracta bsica que es el eje, el autntico tomo del
desarrollo de este tipo de nomencltores que es el ms avanzado de cuantos podemos
tener. Esta idea tendr tres ejes, uno basado en la correcta comunicacin de datos al
sistema (validacin), otro de correcta incorporacin de determinado tipo de datos al
sistema (obtencin) y otro de correcta devolucin de datos del sistema (traduccin).
Estos tres conceptos son el eje operativo bsico y por ello es trascendente su
conocimiento aqu.

Las ideas simples, bsicas, sin profundidades aparentes son las realmente
especiales. Pensemos en la sencillez con que pueden explicarse conceptos topolgicos
como el de los tringulos de Delaunay o los polgonos de Voronoi, por poner dos
ejemplos de uso en topografa. En ellos la idea bsica es sencilla con independencia de
la dificultad de su desarrollo y/o clculo. Esta idea, como base de resolucin del
nomencltor complejo es uno de esos casos y me recuerdan mucho a estas otras citas
clebres:



La mayora de las ideas fundamentales de la ciencia son esencialmente sencillas
y, por regla general pueden ser expresadas en un lenguaje comprensible para
todos (Albert Einstein)
Lo importante no es tener muchas ideas, sino la idea oportuna en cada caso
(Juan Zorrilla)

CONCEPTO DE VALIDACIN

Se define por validacin el conjunto de operaciones que posibilitan de manera
ordenada que una ubicacin dada de la ciudad acabe siendo coincidente con otra del
nomencltor.

La validacin de una direccin, un topnimo, una red o cualquier otra por tanto
consistir en encontrar una equivalencia entre lo que se valida y lo existente en el
nomencltor. De lo anterior y sus implicaciones se deduce que:

- El no lograr resultado positivo en una validacin no significa que lo validado sea
incorrecto, sino que no se ha encontrado en el nomencltor. De ah la
importancia de un mantenimiento continuo del mismo. (Slo un nomencltor
mundial actualizado diariamente podra ser causa de una validacin obligatoria)
- Si un usuario conversa con el sistema, siempre se debe de dar mxima
prioridad a las decisiones de dicho usuario. El nivel de validacin debe de ser
responsabilidad del gestor, nunca del sistema. El sistema est hecho para
ayudarle a tomar la decisin acertada, pero nunca sustituir la decisin
humana. (Pensemos en que el usuario a una determinada fecha a metido el
nombre de la calle oficial ya aprobada mientras el sistema conserva an la
provisional de planeamiento PROVISIONAL MENDEZ ALVARO M 30 CUATRO
se convierte en EROS)
- Es conveniente que el sistema del nomencltor sea capaz de saber antes de
incorporar una direccin <desconocida> que esta ha sido validada. El usuario
habr tomado la decisin que corresponda, pero al menos ha sido usado el


sistema de validacin del nomencltor. (Ello garantiza un filtro necesario para
que el nomencltor no normalizado no se convierta en un almacn de
informacin no validada)
- En un sistema de validacin sin intervencin humana (proceso por lotes) se
debern establecer las metodologas necesarias para una codificacin correcta
(Un ejemplo de lo anterior es la codificacin por pueblo nico. Si en Espaa
slo existe un nombre que se llame pueblo A y pertenece a la provincia
provincia A, podremos modificar el nombre de provincia equivocada. Otros
elementos en este caso fundamentales son los varianteros y las metodologas
estadsticas ya vistas)

Evidentemente y en funcin del contenido de nuestro nomencltor deberemos
ser capaces en un sistema asistido de comunicar a la aplicacin llamante cuando
nuestro nomencltor no es capaz de validar el elemento siguiente de la direccin (por
ejemplo en el nomencltor municipal de Madrid, las direcciones de fuera de Espaa
son slo validables a nivel de pas)

Tabla lgica de estados (casos de uso) de BDC en validacin.


El sistema llamante conoce la situacin en la que ha quedado su validacin. Si es vlida a sus fines o no
lo decidir dicho aplicativo.

Ahora bien, el diseo que un nomencltor haga para que el mismo pueda ser
utilizado desde distintas plataformas ser dependencia de la existencia de las mismas.
En el caso del Ayuntamiento de Madrid, el nomencltor BDC tiene distintas soluciones
tal y como se muestra en el grfico inferior.



Como vemos pues, el nomencltor del Ayuntamiento de Madrid (BDC)
proporciona las siguientes herramientas de validacin:

- Subrutinas: Son programas escritos en NATURAL tipo N (subrutina) que
permiten a travs de un intercambio de informacin (parameter) comunicarse
desde aplicaciones corriendo bajo Z/Os del mainframe con el nomencltor. La
nica componente espacial a la que se puede hacer referencia es a
coordenadas de portales. Tambin estn escritas en RPG para AS400.
- API de BDC: La API de BDC es escalable y consiste en clases escritas en java
enpaquetados en un jar de distribucin que permite la interaccin con el
nomencltor. Tienen un nmero de posibilidades espaciales superior (cercana
de elementos de distinta naturaleza, devolucin de imgenes del mapa). Esta
llamada a BDC es personalizable por la aplicacin origen.
- Aplicacin BDC: El aplicativo llama a una aplicacin web del nomencltor
parametrizando los valores de la direccin. Todo el proceso de gestin de la
interaccin con el nomencltor lo realiza dicha aplicacin que finalmente y por
medio de variables javascript (mismo nombre) se devuelven a la aplicacin
llamante, cambiando la informacin final en su caso y proporcionando a travs
de variables ocultas informacin adicional de estados y otros. Esta llamada
permite un maquillaje de la aplicacin BDC (colores, cabecera, etc), pero de
forma reducida, a cambio prcticamente no hay desarrollo de cdigo por parte
de la aplicacin que la invoca.
- Web Service de BDC: Permite a cualquier dispositivo conectable a internet la
interaccin con BDC, siempre y cuando haya sido dado de alta en el
nomencltor como aplicacin autorizada. Fundamentalmente se usa para la
disposicin de dispositivos o gestores municipales o no, no conectados a la red
municipal. Est abierto a uso pblico.
- SDK de BDC: En realidad ms que un SDK es una aplicacin (actualmente
disponible para Android) que permite un esquema similar al de Aplicacin
BDC en dispositivos mviles en espaol e ingls. Permite la visualizacin de
mapa y geoposicionamiento (Dnde estoy?).



Ejemplo esquemtico de flujo interno de bsqueda de numeraciones de Madrid capital y provincia en
parte del nomencltor del Ayuntamiento de Madrid (Nivel de abstraccin muy alto: No se consideran
otras regiones). Obsrvense los estados de devolucin para control correcto por parte de la aplicacin
llamante. (Funcionamiento interno API)


- Batch masivo de BDC: Servicios no asistidos para validar direcciones. Deben
permitir una codificacin que permita valorar al receptor el alcance de dicha
validacin (similar a los estados en tiempo real)

Cuando una direccin en cualquiera de estos sistemas llega hasta un nivel de
informacin codificada (topnimo, vial, numeracin, etc.) puede ser codificado por la
aplicacin llamante. Lo habitual ser en el caso de un municipio que estemos hablando
de direcciones (cdigo de ndp [n de polica]: cdigo de la numeracin). As el sistema
podr sin ms que guardarse un cdigo saber que esa direccin se corresponde con la
que el nomencltor tenga almacenada con esa codificacin.

CONCEPTO DE OBTENCIN

Se define obtencin como el conjunto de operaciones necesarias en un
nomencltor para que a partir de unos literales SIEMPRE se obtenga una respuesta
codificada por parte del nomencltor.

Ya dijimos que en un nomencltor central es necesario un (sub)nomencltor no
normalizado que ser el correspondiente a direcciones no estables y/o no encontradas
dentro de la parte del nomencltor normalizado. Ah es en donde entra el concepto de
obtencin. Vimos tambin en el apartado de validacin que una direccin en una
aplicacin externa se ver identificada a travs de un cdigo, pero cuando este no es
hallado para cumplir la definicin de obtencin deberemos de integrarla en el
nomencltor no normalizado y dar una respuesta codificada al remitente de la
peticin.

La decisin de que el nomencltor almacene dicha informacin es una decisin
bien institucional, bien del aplicativo. En cualquier caso el nomencltor deber


autorizar dicha operacin. En el caso de BDC dicha autorizacin conlleva el uso
privativo de una identificacin nica del mismo, lo que garantiza tambin al
nomencltor en un uso indebido o masivo la desconexin de dicha aplicacin sin
interferir en el resto de aplicaciones. El modo en que dicha informacin puede
almacenarse se realiza de dos maneras diferentes, cada una de ellas con sus pros y sus
contras:

- Una direccin slo pertenece a la aplicacin que la gener: Este es un criterio
que aumenta el nmero de registros no normalizados en el nomencltor, si
bien tiene ventajas en cuanto a la posibilidad de establecer filtros de aplicacin.
Adems se pueden realizar operaciones de limpieza cuando esos cdigos
despus de aos acaben desapareciendo del sistema original. La ventaja radica
en que cualquier operacin realizada slo afecta a la aplicacin duea de la
direccin.
- Una direccin es compartida por cualquier aplicacin independientemente de
su origen: En este caso el tamao a reservar para el nomencltor no
normalizado ser inferior, no obstante se anula la posibilidad de modificaciones
slo de aplicativo y se complica la posibilidad de limpieza.

En el nomencltor municipal de BDC el criterio es el primero de los posibles. La
experiencia nos demuestra que las aplicaciones desean tener sus no normalizados y
participar en la toma de decisiones sobre ciertos aspectos de su mantenimiento.
Adems la capacidad de limpieza se ha demostrado muy interesante a lo largo del
tiempo, no obstante no se puede descartar la segunda opcin en funcin de otros
criterios que sean distintos a los ptimos para el caso del Ayuntamiento de Madrid.

El nomencltor no normalizado diseado para BDC es simple en cuanto a
concepcin. Para BDC una direccin no normalizada est formada por sus literales
tipo de va, nombre de va y numeracin por aplicativo, de manera que se les asocia
informacin adicional (atributos), adems de poder tener georreferenciada su
posicin. Los procesos de mantenimiento sobre las direcciones no normalizadas
suponen a veces la modificacin de dichos atributos, con lo que se genera una historia
de atributos bajo ese mismo cdigo (supongamos una modificacin de cdigo postal,


por ejemplo). Por otro lado los procesos de normalizacin de provincias, poblaciones,
viales y numeraciones para toda direccin de la Comunidad de Madrid y de provincias
y poblaciones para el resto hacen que la propia direccin cambie su contenido
fundamental (imaginemos un cambio de denominacin de una va que est en no
normalizados por no haberse encontrado la numeracin), de manera que se genere
automticamente un nueva direccin no normalizada con el contenido actualizado y
sin prdida de atributos.

En el anterior escenario podemos preguntarnos cmo es posible cambiar un
cdigo a una aplicacin externa? La respuesta es simplemente que no podemos o
cuanto menos no debemos. Eso supondra procesos aadidos y delegar problemticas
del nomencltor a los usuarios del mismo. Lo que el sistema debe de hacer es al igual
que hace con los atributos para una determinada codificacin, lograrlo entre
direcciones no normalizadas y entre estas y las normalizadas, de manera que al usuario
operativamente le sea ajena la evolucin en la normalizacin de cualquier direccin de
nuestro nomencltor.

La idea anterior es bsica en cuanto al siguiente apartado que veremos, pero
tambin es trascendente en este, ya que dicha operativa produce un nivel de aciertos
a largo plazo al irse generando de manera progresiva un conjunto de variantes a
direccin completa que incluso podran llevar al usuario a una direccin normalizada.

En el grfico siguiente podemos ver como una direccin que entr en el
instante T1 ha evolucionado a los instantes T2 por modificaciones en sus atributos
(seccin censal) y al instante T3 por modificaciones en la denominacin de la calle, de
manera que en instante T4 dicha direccin se normaliza a un cdigo conocido (por la
aparicin de su numeracin en dichos normalizados). El usuario conoce la historia de
esa direccin en cualquier instante (si dicho aplicativo llamante va a jugar con la
temporalidad de una direccin, deber guardarse como mnimo el instante de
bsqueda, que ser el momento de alta en SU sistema). Todas estas operaciones
internas del nomencltor sern transparentes a la aplicacin que lo usa.



Generacin de historia de una direccin no normalizada independientemente de la aplicacin que la
gener FIGURA: OBTENCION I**


A la hora de incorporar direcciones no normalizadas (e incluso realizar
bsquedas dentro de no normalizados), ya hablamos en el apartado de validacin que
ello se realizara con garantas. Efectivamente se precisan mecanismos que aseguren la
calidad de la informacin de entrada. El flujo que en BDC se ha incorporado consiste en
un campo obligatorio a la hora de realizar llamadas a obtencin en no normalizados
llamado intercambioBDC y el cual contiene informacin encriptada del ltimo
contenido validado. Dicha encriptacin no es pblica, de manera que el nomencltor
obliga al uso de dicho parmetro que es devuelto en las validaciones. Ese parmetro
ser obligatorio para poder entrar a obtencin. Si una aplicacin cambia la informacin
de entrada respecto a la ltima validada, el nomencltor lo sabr sin ms que
reencriptar la entrada y compararla con el parmetro enviado, de manera que
generar un error correspondiente a la necesidad de una nueva validacin (Si precisa
encriptaciones ms seguras es aconsejable usar modelos como Advanced Encryption
Standard o modelos ms simples pero muy tiles como el uso de nmeros resultantes
del uso de tcnicas de dgito de control final en base a operaciones EBCDIC o ASCII
sobre los datos de entrada). Supuesto lo anterior correcto, el sistema comprobar de
la no existencia previa de dicha direccin no normalizada, de manera que establecer
un mecanismo para integrarla en su caso, lo cual en BDC se hace a travs de una
parametrizacin del campo alta de llamada. De esta manera la aplicacin llamante en
funcin de los permisos atribuidos al usuario podr o no realizar determinados tipos
de alta (altas de forma condicionada en nomencltor no normalizado). Dicha
parametrizacin en el caso del nomencltor del municipio de Madrid tiene las
siguientes posibilidades:

- No dar alta. Slo buscar si existe la direccin en el nomencltor de no
normalizados.
- Dar alta condicionada a la existencia del vial (numeraciones)
- Dar alta condicionada a la existencia de la numeracin (locales)
- Dar alta siempre.

Esta es la manera en la que un determinado departamento puede tener acceso
a dar un determinado tipo de alta de un domicilio (nmeros no existentes, por
ejemplo), mientras que deber de ser autorizado por terceros para poder dar un alta


de un domicilio cuya calle no haya sido encontrada. Con ello el nomencltor no
normalizado dar cobertura adecuada a ciertos condicionantes que tienen algunos
aplicativos en la calidad de la informacin.

La obtencin slo es posible en BDC a partir de API, ya que su lgica es muy
simple (muy fcil de incorporar a la lgica de cualquier aplicacin). Hasta el momento
ninguna aplicacin no municipal tiene acceso a consultar o incorporar informacin en
el nomencltor no normalizado del Ayuntamiento.

Sistema de acceso y alta al nomencltor no normalizado de BDC



Esquema de funcionamiento interno del aplicativo en obtencin (1 Madrid 3 CAM 9 NN)

CONCEPTO DE TRADUCCIN

Se define traduccin como el conjunto de operaciones necesarias en un
nomencltor para proporcionar el literal actual o histrico a una fecha dada a partir
de una codificacin proporcionada previamente por dicho nomencltor.

Efectivamente todo el sistema previo va encaminado a dos posibilidades, una
de ellas enfocada a la validacin de informacin codificada normalizada (validacin) y
otra enfocada a la validacin y obtencin de informacin codificada sea o no


normalizada (validacin + obtencin). De nada servira nuestro nomencltor si ste no
fuese capaz de devolver la ubicacin en un momento dado a partir de dicho cdigo.

Si atendemos al grfico que vimos en CONCEPTO DE OBTENCIN (FIGURA:
OBTENCION I**) las respuestas que nuestro nomencltor dar en funcin de la fecha y
hora de llamada correspondern a cmo era la informacin en ese momento. As
tendremos el siguiente esquema:

LLAMADA

RESPUESTA

Cdigo Instante T Ubicacin Atributos
cdigo A T>=T1 y T<T2 A NN en T1
cdigo A T>=T2 y T<T3 A NN en T2
cdigo A T>=T3 y T<T4 B NN en T3
cdigo A T>=T4 C N en T4
Respuestas de traduccin en una secuencia temporal T de T1 a T4

Evidentemente esto mismo suceder con datos normalizados, de manera que si
consultamos el cdigo correspondiente a la C/ Alcal 706 antes del 25/09/1992
obtendremos la Avenida de Aragn n 296-C

Lgicamente esta operacin que aparentemente es sencilla es una de las ms
complicadas de analizar y desarrollar. Caben soluciones intermedias basadas en
procesos batch que generen tablones de toda la historia de cada una de las
direcciones, pero esto no debe de ser la base del funcionamiento de nuestro sistema,
puesto que dicha generacin no se puede realizar mientras est abierto el tiempo real
(los usuarios interactan con el sistema a travs de aplicaciones de escritorio). En
cualquier caso, aparte de disponer de utilidades de traduccin implementadas a travs
de API y Web Service, se hace necesario disponer de un sistema de traduccin BATCH
para grandes volmenes de informacin. Pensemos que no es infrecuente el
procesamiento BATCH de tres o cuatro millones de registros a traducir en tiempos que


idealmente debern rondar una productividad de proceso de entre 600 y 1.200
registros traducidos por segundo.

ESQUEMA DE USO Y VENTANAS

Intentaremos aqu proporcionar un esquema bsico en el que se integran las
tres funcionalidades en las que se apoya el funcionamiento de nuestro nomencltor a
nivel geomtico. Se trata pues de comprender despus de realizada la lectura previa la
sencillez del sistema de cara a su uso. Un nomencltor es imprescindible que sea
simple y sencillo de cara al exterior, an cuando ya sabemos a estas alturas la
complejidad que representa internamente.

Tras este simple diseo se encuentran multitud de funcionalidades disponibles,
pero no ser necesario ms que ese cdigo para lograrlas. Evidentemente esta no ser
la nica funcionalidad disponible del nomencltor, pero si la fundamental. Todas las
dems se realizarn en esencia a partir de esto mismo.



Veamos ahora varios ejemplos de uso de las API proporcionadas por BDC
(nomencltor del Ayto. de Madrid) para poder realizar estos procedimientos
estudiados. En primer lugar veremos un ejemplo de cmo se realiza una traduccin y
luego veremos una validacin de un vial.



Ejemplo 1 : ACCESO A BDC POR TRADUCCIN
package ejemplos_proyecto;
import cicsepi.traduccion.*;
public class dameUbicacion {
public static void main(String[] args) {
try {
CTraduccion traduccion = null;
traduccion = new CTraduccion("9", "1603355", "", "", "", "", "APLIC");

/* Habra que analizar los datos siguientes */
System.out.println(traduccion.getEstadoTraduccion());
System.out.println(traduccion.getEstadoDireccion());

/* Si todo bien, recogemos los datos del nomencltor */
System.out.println(traduccion.getDatosDireccion().getNom_clase());
System.out.println(traduccion.getDatosDireccion().getNom_vial());
System.out.println(traduccion.getDatosDireccion().getNom_app());
System.out.println(traduccion.getDatosDireccion().getNum_app());
System.out.println(traduccion.getDatosDireccion().getCal_app());
} catch (Exception e) {
e.printStackTrace();
}
}
}

Ejemplo 2 : ACCESO A BDC POR VALIDACIN DE POBLACION
package ejemplos_proyecto;

import cicsepi.conexion.*;
import cicsepi.validacion.*;
import cicsepi.validacion.entidades.*;
import java.util.ArrayList;

public class damePueblo {
public damePueblo() {
super();
/* Por comodidad lo meto como argumento para poder probar. */
public static void main(java.lang.String[] args) {
CConexion conexion = null;


try {
String poblacionValidar = "";
String codProvincia = "";
ArrayList poblaciones = null;
int numPoblaciones=0;
CPoblacion unapoblacion;
String[] argumentos = args;

if (argumentos.length>=2) {
codProvincia = argumentos[0];
for (int i=1; i<argumentos.length - 1; i++) {
poblacionValidar = poblacionValidar.concat(argumentos[i]);
poblacionValidar = poblacionValidar.concat(" ");
}
poblacionValidar = poblacionValidar.concat(argumentos[argumentos.length-1]);
conexion = new CConexion();
CValidarPoblacion validaPoblacion = new
(CValidarPoblacion(conexion,codProvincia,poblacionValidar);
int estado = validaPoblacion.getEstado();
String mensaje = validaPoblacion.getMsg_estado();
System.out.println("Mensaje asociado a la validacin:");
System.out.println(mensaje);
poblaciones=validaPoblacion.getPoblaciones();
numPoblaciones=poblaciones.size();
if (estado==0){
unapoblacion=(CPoblacion)poblaciones.get(0);
System.out.println("Se ha encontrado una sola poblacin:");
System.out.println("Cdigo de provincia: " + unapoblacion.getCod_provincia());
System.out.println("Cdigo de poblacin: " +
unapoblacion.getCod_poblacion());
System.out.println("Nombre de poblacin: " +
unapoblacion.getNom_poblacion());
System.out.println("Tipo de poblacin: " + unapoblacion.getTip_pueblo());
System.out.println("Cdigo de municipio: " +
unapoblacion.getCod_municipio());
} else if (estado==1){
System.out.println("Se devuelven varias poblaciones hasta un lmite de 50:");
for (int i=0; i<numPoblaciones; i++) {
unapoblacion=(CPoblacion)poblaciones.get(i);
System.out.println("Poblacin nmero: " + (i+1));
System.out.println("Cdigo de provincia: " +
unapoblacion.getCod_provincia());


System.out.println("Tipo de poblacin: " +
unapoblacion.getTip_pueblo());
}
} else if (estado==2){
unapoblacion=(CPoblacion)poblaciones.get(0);
System.out.println("Se encontra una sola poblacin parecida);
System.out.println("Cdigo de provincia: " + unapoblacion.getCod_provincia());
System.out.println("Tipo de poblacin: " + unapoblacion.getTip_pueblo());
} else if (estado==-1) {
System.out.println("No se ha encontrado nada en nomencltor);
} else if (estado==-2) {
System.out.println("El cdigo de provincia es incorrecto");
}
} else {
System.out.println("Introduzca argumentos.");
}
System.out.println("Se ha producido un error");
} finally {
if (conexion !=null) {
try {
conexion.close();
System.out.println("Problemas al cerrar la conexin");
}
}
}
}
}

Vemos como en los ejemplos arriba indicados estamos manejando los estados
de devolucin (ejemplo de validacin de pueblos) y en ambos casos todo el manejo se
hace a travs de objetos. El objeto es un elemento ligado a la clase de forma general


que posibilita un manejo simple de la informacin (CTraduccion, CPoblacion son los
manejados en nuestros ejemplos). Las llamadas a mtodos de la clase se han
identificado en rojo y las respuestas en verde (observese como cuando se devuelve
ms de una poblacin propuesta la forma en que se recorre el array de objetos
devolucin)

Acompaando a toda esta metodologa debe de haber siempre un conjunto de
herramientas que puedan proporcionar al usuario informacin del nomencltor
(operativa intranet / internet [parcialmente]) un conjunto de herramientas que
puedan proporcionar al usuario informacin del nomencltor bien en obtencin, bien
en traduccin. No debemos de olvidar que aunque mostremos pantallas del entorno
distribuido de servidores Windows, la funcionalidad debe de estar disponible en todos
los sistemas (mainframe, AS400, distribuido y mvil).

Ejemplo de pantalla del nomencltor en la intranet para consultar direcciones de aplicacin



Con estos ejemplos hemos cerrado el captulo fundamental del diseo lgico de
un nomencltor municipal. Esto nos servir de base para un correcto modelado de la
BBDD, as como para gestionar el sistema de forma adecuada. No olvidemos que esta
es la base. A partir de aqu, es cierto, veremos utilidades nuevas y posibilidades de
respuesta pero lo aqu visto son los cimientos, la idea sencilla cuyas interioridades
sern realmente la tarea principal de que el sistema est vivo, que es la caracterstica
elemental que hace a un nomencltor una herramienta til aqu y en cualquier lugar
en donde se haga necesario su uso.

Ejemplo de pantalla del nomencltor en la intranet para traducir un cdigo de aplicacin con fecha.



5
DISEOS ESTRATGICOS

Bajo este ttulo se intenta agrupar el cmo se ha de realizar el diseo de base
de datos del nomencltor y los elementos bsicos del diseo geomtico respecto a la
cartografa asociada que tienen interaccin mxima con el diseo no espacial. Por otro
lado es interesante el conocimiento de la directiva INSPIRE de cara a ver cmo puede
abordarse una transicin de modelos y por ltimo un estudio sobre el modelado de
servicios IDEE haciendo especial mencin a los que a mi modo de entender son bsicos
en un nomencltor de una gran Administracin Local.

No se realizar aqu tanto una descripcin de campos y tablas utilizadas, como
un estudio de bloques concretos de su estructura de manera que de su conocimiento
podamos ser capaces de implicarnos con garantas en un proyecto como el analizado.
En cuanto a BBDDEE estudiaremos aquellas tablas que directamente sean utilizadas
por el diseo estudiado viendo distintas alternativas. Bajo mi punto de vista y siempre
que sea posible el SIG y la base alfanumrica del nomencltor estn tan ntimamente
relacionados, que debe de haber una serie de capas base cartogrficas absolutamente
conectadas formando un nico bloque denominado nomencltor al que despus,
lgicamente se le aadirn otros modelados independientes, que ya no estarn
ntimamente relacionados con l ni con ningn elemento indirectamente asociado.

En el sentido del prrafo anterior, es frecuente ver en artculos, conferencias y
noticias soluciones realmente innovadoras en cuanto al tema general IDEE y de cmo
se han conseguido resultados sorprendentes. No quito ni un pice de mrito a todo
ello (soy consciente de su dificultad), pero normalmente la realidad que subyace
desgraciadamente no siempre es tan maravillosa como se pinta y en lugar de presentar


las dificultades y los errores como una oportunidad para que no sean cometidos por
otros, se ocultan intilmente, pues sin duda ese error ser cometido nuevamente por
otros haciendo un flaco favor a la ingeniera en su avance.

Resumiendo y tras estos breves apuntes, el contenido que se pretende
desarrollar en el captulo es:

- Diseo lgico de la BBDD del nomencltor
- Relaciones de la anterior con la BBDDEE
- El modelado segn la directiva INSPIRE
- Los servicios fundamentales de IDEE (INSPIRE) en el nomencltor

Con estos diseos y junto al anlisis funcional del aplicativo (normalmente
ambos estudios acaban al tiempo al estar ntimamente relacionados) sentaremos los
verdaderos cimientos de nuestro nomencltor.

El hombre que ha cometido un error y no lo corrige comete otro error mayor.
(CONFUCIO)
Si cerris la puerta a todos los errores, tambin la verdad se quedar fuera.
(Rabindranath Tagore)
Cada vez que cometo un error me parece descubrir una verdad que an no conoca.
(Maurice Maeterlinck)
Los errores ajenos proporcionan los medios para descubrir la verdad.
(John Selden)


LA BASE DE DATOS

El modelado fsico, pero fundamentalmente el lgico (al depender aqul de
este) de nuestras bases de datos son la base sobre la que habrn de sustentarse todas
las respuestas que nuestro sistema habr de responder (anlisis funcional). Es por ello
de mxima importancia que no slo diseemos en base a la facilidad de integracin de
datos, sino fundamentalmente a la obtencin rpida de aquellas respuestas. El
modelado lgico, por tanto tendr en cuenta los campos de cada tabla atendiendo a su
identificacin lgica, as como las relaciones entre los distintos campos de tablas
diferentes. Se trata de un diseo asptico en el que el soporte de implementacin del
gestor de BBDD no importa. Se podr implantar en cualquier gestor relacional.

A la hora de implementar el diseo lgico en uno fsico es cuando el sistema a
usar tiene su verdadera importancia, pues los tipos de datos de cada gestor varan y
habr que estudiar en cada caso cual es el conveniente y que longitud o tamao de
datos es el ptimo. Personalmente acostumbro en el diseo lgico a dar ciertas
caractersticas aspticas del fsico, por ejemplo especifico N si el campo va a ser
numrico (sea cual sea despus el tipo ptimo elegido), A si se va a tratar de cadena
de caracteres de cualquier tipo y B si se trata de un operador lgico o semafrico. La
experiencia me dicta que los tipos de datos deben de ser lo ms simples posibles,
porque eso har que cualquier modificacin del gestor sea ms sencilla de resolver si
se da la circunstancia.

Antes de profundizar sobre el modelado propuesto, iniciaremos este apartado
viendo algunas caractersticas que son imprescindibles para poder no slo realizar una
lectura de cualquier diseo, sino sobre todo y lo que es ms importante para poder
realizar el diseo en s mismo. Adems pondremos ejemplos sobre uno de los gestores
ms extendidos y profundizaremos sobre el mismo: SqlServer.



CONCEPTOS PREVIOS

Una base de datos, como ya sabemos, no es ni ms ni menos que una coleccin
de ficheros relacionados entre s con el fin de almacenar datos y poder acceder
cmodamente a ellos con la posibilidad de manipularlos y/o consultarlos. De los
niveles que tenemos en una BBDD el nico que no nos interesa en este momento es el
conceptual, ya que representa parcialmente el diseo global, de cara a que sea
ocultado para ciertos usuarios, en funcin del desempeo de su trabajo (vistas de
tablas). Por tanto nos centraremos en el modelado lgico y fsico.

Niveles de informacin en una BBDD segn Takeshi Huamani Chaupin (Instituto SISE)



El modelo de abstraccin ms alto dentro del diseo lgico de una BBDD es el
generalista que pretende ir de lo general a lo particular desgranando progresivamente
entidades. Personalmente lo utilizo muy poco, pero es interesante cuando nos
enfrentamos a nuevos diseos. Suele ser usado en los primeros estadios del proyecto,
pero veremos que en seguida nos derivamos hacia el modelo lgico puro (en esto la
experiencia es fundamental), el cual solemos resolver a travs de los denominados
diagramas de entidad-relacin (modelo entidad-relacin). Un modelo E-R nos permite
representar las entidades relevantes de cualquier sistema de informacin as como sus
propiedades y sus relaciones.

Dentro de un diagrama E-R tendremos los siguientes elementos:

- ENTIDAD: Objeto del mundo real (fsico [concreto] o no [abstracto]) que se
diferencia de cualquier otro e incluso del mismo tipo unvocamente, es decir
que aunque se trate del mismo objeto existe diferenciacin. Efectivamente, la
entidad calle se diferencia de la entidad municipio y adems una calle se
diferencia de cualquier otra, puesto que cada uno tiene caractersticas propias
(por ejemplo, el nombre, el trazado). Dentro de las entidades podemos
distinguir las denominadas entidades regulares y las dbiles, que son aquellas
cuya existencia precisa de una entidad regular para que sea identificable.
- RELACIN: Es la asociacin o dependencia entre dos entidades. La cardinalidad
de una relacin permite saber cmo es esa relacin. La cardinalidad de la
relacin se expresa anotando un determinado cardinal asociado a la entidad y
ser 0 si la entidad no est obligada a participar de la relacin, 1 si participa
una vez (punta de flecha) y N * si no est obligada a participar en la
relacin o puede hacerlo un nmero indeterminado de veces. Ms raro aunque
posible son cardinalidades fijas 2,3,4
- ATRIBUTOS: Es el conjunto de caractersticas que tiene una entidad (atributos
de la entidad) o una relacin (atributos de relacin). Es importante intentar
encontrar la mayora de atributos posibles y de entre ellos luego escoger los
fundamentales y prescindir incluso de algunos de ellos que finalmente no
resuelven preguntas de nuestro anlisis, ni se prev que lo haga. El atributo de
una calle podr ser su cdigo, su fecha de recepcin municipal sin embargo,


pensemos que su nombre puede ser considerada otra entidad con la cual se
relacionar. Cuando un atributo forma parte de la clave primaria suele
subrayarse en el diagrama.
- DOMINIO: Es una lista de valores que puede tomar un determinado atributo.
Lgicamente habr atributos en los que podamos establecerlo y otros en los
que no.
- HERENCIA Y AGREGACIN: Inicialmente no formaba parte de los diagramas E-R,
pero el creciente diseo por objetos ha introducido esta caracterstica tipo del
diseo OO. Hoy en da existen gestores como ORION, OpenOODB, IRIS, ODE y
otros comerciales como GEMSTONE/OPAL , ONTOS, Objectivity, Versant ,
ObjecStore y O2. En general no nos vamos a encontrar, por el momento, con
estos gestores y qu duda cabe que presentan ms de un inconveniente con
respecto al diseo relacional, por lo que los obviaremos en nuestro estudio,
aunque hemos de decir que la mayora soportan los dos lenguajes ms
extendidos en OO (java y C#).

La manera de representar en diagrama estos elementos es la siguiente:



De entre los atributos de una entidad hay algunos que por sus caractersticas
son necesarios conocer. As tendremos atributos especiales:

Clave PRIMARIA (PX): Es el atributo que identifica una entidad de forma inequvoca.
Automticamente no podr ser considerado el valor nulo (Hay BBDD que admiten un
nico nulo, aunque es extrao e inconveniente). En ANSI SQL se denomina PRIMARY
KEY. En SqlServer tendremos

ALTER TABLE <identificador_de_la_tabla>
ADD [ CONSTRAINT <identificador_de_la_directiva> ]
PRIMARY KEY ( <nombre_de_columna> {, <nombre_de_columna>}... )

NDICE NICO (IX): Siempre una clave primaria es ndice nico, no obstante podemos
tener otras claves que identifican de forma nica un registro de la entidad. El acceso
establecindole como ndice mejorar. A veces se las denomina clave alterna. En
SqlServer tendremos

UNIQUE ( <nombre_de_columna> {, <nombre_de_columna>}... )

NDICE NO NICO (IX): Se utiliza cuando a pesar de no ser nico (habr duplicados) va
a haber un gran nmero de accesos a travs de l. Suelen ser claver forneas en
muchos casos. En SqlServer tendremos



( <nombre_de_columna> {, <nombre_de_columna>}... )

CLAVE FORNEA (FK): Se trata de un ndice nico o no nico que es utilizado para
relacionarse con una clave primaria o ndice nico de otra tabla. Relacin entre
entidades.

En SqlServer debemos adems de conocer una divisin entre ndices especfica
del gestor. A saber:

- ndice agrupado
Acta sobre la propia forma de almacenar los datos. Normalmente los datos de
una tabla se almacena en una estructura desordenada llamada montn que
estar formado normalmente por varias columnas formando dicho ndice
agrupado, de manera que la respuesta por defecto de una select vendr
ordenada de acuerdo a dicha agrupacin. Slo se permite un ndice agrupado
por tabla. El rendimiento se ver afectado. Hablamos normalmente de tabla
agrupada cuando sucede esto.

- No agrupado
Los ndices no agrupados tienen una estructura separada de la BBDD con lo que
no ralentizan tanto al sistema, de manera que estos tienen un puntero a la fila
de datos correspondiente (localizados de fila), cuya estructura depende de si la
tabla est agrupada o no.



Un ltimo detalle para un correcto diseo de una BBDD es el conocimiento de
las llamadas formas normales. La experiencia es el mejor aliado de cuando conviene o
no saltarnos una forma normal, pero de forma general habremos de tenerlas presente.
A modo de recordatorio, las escribimos aqu de acuerdo a la definicin del Doctor
Eugenio Santos Menndez de la Universidad Politcnica de Madrid:

1. Se dice que el esquema R(T,L) est en 1FN (primera forma normal) si en l no
existen atributos multivaluados. En definitiva, que un registro no se incluya
realmente dentro de s lo que deberan de contener varios registros.
2. Se dice que el esquema R(T,L) est en 2FN si est en 1FN y adems todos sus
atributos no principales tienen dependencia funcional completa respecto de
todas las claves existentes en el esquema. En definitiva no mezclar datos que
no son exactamente propios de la entidad.
3. Se dice que el esquema R(T,L) est en 3FN cuando est en 2FN y adems ningn
atributo no principal depende transitivamente de alguna de las claves
existentes en el esquema.

En general las formas normales nos ayudan a realizar un diseo ptimo de la
BBDD, no obstante, como ya se ha dicho, muchas veces es necesario deshacer una
forma normal en pro de la simplificacin y siempre en la seguridad de que realmente
eso es lo que conseguimos. Como regla general deben de ser cumplidas. Hay ms
reglas formales, pero estas sern las prioritarias para una correcta normalizacin de
nuestro diseo.

Queremos decir aqu que ltimamente se est utilizando un sistema
denominado NHibernate (si programamos en C#) e Hibernate (si programamos en
java) para desvincular el entorno de programacin del gestor de la capa de base de
datos (JDBC tambin independiza) a travs de una serie de descripciones XML del
diseo, los cuales son usados y traducidos por la herramienta en funcin del gestor al
que apuntemos. Se trata de un sistema de programacin interesante si prevemos
ventas multiplataforma o se prevn continuos cambios en el gestor de BBDD que


vayamos a utilizar. De otro modo y salvo los casos comentados, siempre y cuando
intentemos usar SQL estandarizado, no me parece una buena idea, pues aumenta la
complicacin y el tiempo de programacin sin beneficio alguno (En la experiencia
propia de traslado de gestor DB2 a SqlServer el 99,8% de las sentencias funcionaron a
la primera, siendo las modificaciones rapidsimas).

Por ultimo comentar que para realizar este tipo de diseos, tanto en lo que es
anlisis funcional de aplicacin como en el diseo de la BBDD se usan herramientas
CASE. Me parecen especialmente interesantes para esta parte del diseo ArgoUML
como versin libre y ErWIN como CASE propietario.

DISEO DE LA BASE DE DATOS

Estudiaremos el cuerpo bsico del diseo de los subnomenclator. Ese cuerpo
bsico es una estructura que se puede reaprovechar en general en el mbito de las
AALL abarcando en ella el nomencltor propio, metropolitano y estatal.

Diseo de nomencltor intrnseco:

A la hora de disear un posible nomencltor intrnseco deberemos de
establecer que tablas van a ser espaciales (azul) y cules no (rojo). Al mismo tiempo
durante el tiempo de diseo irn surgiendo dudas acerca de si tenemos que responder
o no a ciertas preguntas (Vamos a tener una entidad de puntos de inters?, Se
relacionarn obligatoriamente o no con un portal?). A estas respuestas la experiencia
nos dicta que habr posible relacin, pero esta no ser obligatoria. Adems deberemos
de decidir si un punto de inters representar un evento codificable o no del
nomencltor (concepto validacin-obtencin-traduccin para puntos), lo cual hoy en
da es sumamente aconsejable para determinados casos (atestados, por ejemplo, que


permitirn realizar anlisis ulteriores de puntos negros, por ejemplo). Si decidimos que
un POI sea parte de las ubicaciones de nuestro sistema no debemos olvidar que slo
debemos mantener la parte geomtrica y asociaciones del mismo con el nomencltor,
y no elementos propios del sistema que lo usa. En el diagrama E-R, adems vemos
como al tratarse de un nomencltor municipal hemos decidido que las capas poblacin
y municipio no sean espaciales (podran serlo para slo un caso: el de la propia
poblacin).

Hemos decidido la forma de codificar topnimos a travs de un cdigo de vial y
vemos que ello cumple todos los requisitos (se le puede asociar un mbito superficial a
travs de un subvial y se puede rotular de cara a la obtencin de visualizacin
cartogrfica). Tambin vemos como a partir de los subviales ser posible obtener los
cruces de calles por la codificacin de subviales como pertenecientes a varios viales
(vemos la cabida de una relacin N:N) y por anlisis espacial podremos realizar solapes
de topnimos con subviales (caso de colonias, UVA, etc.). Nos preguntamos si tiene
cabida un diccionario (es sumamente aconsejable en la informacin normalizada) para
las numeraciones (tipos fijos como KM., NUM, BLQ o cualesquiera de la realidad de
nuestra ciudad) y en el caso de tipos de vial (CALLE, CUESTA, AVENIDA, etc.). Hemos
intentado generar un diseo casi completo que ser modificado en funcin de la
velocidad de respuesta necesaria, pero al mismo tiempo hemos dejado abierta la
posibilidad de pensar sobre el diseo. As por ejemplo podemos pensar en el atributo
nmero de plantas en un edificio, que sin duda es de gran ayuda a la hora de
restringir las plantas en locales, no obstante cabe preguntarse dispondremos de dicha
informacin?: Esta es la pregunta clave en este caso. Muchas veces un diseo es ideal
y despus surgen las adaptaciones en funcin de la realidad.

No quiero pasar por alto el hecho de que las relaciones N:N (recordemos que la
punta de flecha indica 1, sin tener que ponerlo) siempre se resuelven uniendo las dos
entidades a travs de una tabla intermedia. Por ejemplo la relacin entre los nombres
de numeracin y portales se resolvern codificando a travs de fecha y hora los dos
cdigos (el de nombre de numeracin y el de portal). Esto siempre es as en diseo
fsico pues sino no estaramos atendiendo al cumplimiento de las formas normales (En
el diagrama E-R se han codificado como RELATOR). En el diseo de dos pginas ms
abajo (***) vemos parte de la implementacin concreta de BBDD (diseo fsico) en el
Ayuntamiento de Madrid en el que se han alterado algunas de las caractersticas del


diagrama E-R ideado bajo estas lneas y en el que todas las tablas, menos la de PORTAL
(NDP) son alfanumricas.

Extracto del modelo E-R para el nomencltor intrnseco


Implementacin parcial (diseo fsico) del nomencltor propio (SqlServer)(***)



Implementacin parcial del diseo fsico del nomencltor metropolitano y estatal (SqlServer)



Diseo de nomencltor metropolitano y estatal:

En la pgina anterior vemos la implementacin sencilla de los dos
nomencltores metropolitanos y estatales. El hecho de tener agrupaciones diferentes,
no slo adapta la realidad de lo necesario al diseo, sino que simplifica las labores de
actualizacin de la informacin. En el caso del Ayuntamiento de Madrid, la tabla
CMDA020, correspondiente a las numeraciones, tiene componente espacial. Nos ha
parecido interesante aqu poner parte del diseo de provincias, municipios etc. y su
interrelacin con ambos callejeros. Ya vimos en su da como estos nomencltores
deben de adaptarse especficamente a las preguntas necesarias sobre ellos al tiempo
de que su diseo debe de ser acorde con la realidad porcentual de la respuesta
requerida en funcin del mbito del nomencltor.

Vamos a desarrollar aqu (ver figura siguiente) el diagrama del nomencltor no
normalizado reducido, pues es el resultado de algunas experiencias que estn
resultando altamente positivas con un diseo relativamente simple.

En el diseo y aunque se trata de una complicacin de cara a la traduccin de
direcciones los elementos no normalizados de la entidad no normalizados se pueden
relacionar con otros elementos de la misma entidad (hay diversas soluciones fsicas
para realizar esto), pero tambin con otros elementos de entidades normalizadas.
Adems puede darse que un POI no normalizado genere un literal no normalizado y
viceversa, con lo que se puede asignar un texto a la posicin o una posicin al texto.
Ello duplica las posibilidades de normalizacin ante la existencia de geometra y por
medio de varianteros o coincidencias futuras a travs de los atributos. En estos casos
estaremos ante una normalizacin parcial que nos permite muchas operaciones
adicionales. Al intentar simular un tiempo de diseo podramos ver la necesidad o no
de que los POI no normalizados estuvieran ligados a una aplicacin (recomendable).
Hemos puesto en morado las tablas propias del diseo no normalizado.



Diagrama parcial E-R de nomencltor no normalizado. Relaciones Alfanumricas y espaciales.



DISEOS ESPECFICOS

Conocemos por diseos especficos aquellos que an no siendo pertenecientes
al nomenclator municipal resultan una componente naturalmente asociable a
elementos del propio nomenclator y que por su naturaleza generalista y/o carcter
trascendental se entiende deben considerarse parte integrante del sistema
nomencltor municipal, como servicio propio de ubicaciones y sus asociaciones en la
ciudad.

Los diseos especficos ms importantes en el Ayuntamiento de Madrid son:

- Codificacin postal para fuera de la Comunidad Autnoma
- Seccionado de cartera y codificacin postal para la Comunidad Autnoma
- Informacin estadstica del Seccionado Censal y asociaciones Distrito y Barrio
- Gestin de la zonificacin y distribucin de datos para Servicio de
Aparcamiento Regulado Municipal (SER)
- Gestin de los ndices fiscales del municipio.
- Gestin de las zonas de fiscalidad del municipio.
- Informacin catastral de parcelas del municipio.
- Gestin de dualidad en los sistemas de referencia.

No entraremos por el momento en detalle en todos estos diseos, pues se
vern de manera ms pormenorizada en el siguiente captulo. Tan slo decir aqu que
cada uno de ellos son subsistemas que pueden ir desde una simple tabla hasta un
mayor o menor complejo entramado del diseo E-R, pero que en cualquier caso son
datos que debern ser proporcionados (y esto es muy importante) de forma genrica
por el sistema en la mayora de los casos. Al mismo tiempo habr de realizarse el
anlisis funcional y la programacin de todos los procesos cuyo mantenimiento se
realice en el propio nomencltor (en todos los especificados arriba as sucede).
Veremos por poner un ejemplo el subsistema del nomencltor de cdigos postales a
travs de la definicin de las tablas que lo completan.


Hemos de decir que el Departamento de Estafeta Municipal se encarga de
actualizar de forma puntual las incidencias que el Organismo Autnomo Correos y
Telgrafos nos comunica como incidencias, producindose cargas completas cuando
dicho Organismo Autnomo lo considera o detectamos un porcentaje de problemas
excesivo de acuerdo al control de calidad tanto de la Estafeta Municipal como del
propio Correos. El problema es distinto en el caso de que estemos en la Comunidad
Autnoma que fuera de ella. Por motivos logsticos, Correos no podra absorber el
volumen de trabajo proporcionado diariamente por el Ayuntamiento de Madrid si
desde este la gestin queda resuelta, de manera que para poblaciones de la
Comunidad Autnoma distintos de Madrid, resolvemos los enrutamientos posibles, as
como para toda direccin no slo la codificacin postal correcta, sino el cartero
(numrico) que repartir. De esta manera el Ayuntamiento de Madrid empaqueta la
informacin lista para que el cartero la reparta. Para el resto de Espaa slo es
necesaria la codificacin postal, debido a que el volumen se reduce muy
considerablemente, de manera que la gestin no necesita intervencin humana
continua, sino actualizacin a todos los cierres de nueva codificacin de correos, lo
cual es tarea propia de los gestores de BDC.

Adems de las tablas propias de mantenimiento e identificacin de datos
postales, existen aplicaciones de consulta sobre ellas para el personal municipal, as
como la posibilidad de obtencin de listados a demanda con criterios personalizables.

Ejemplo de datos postales completos en informacin de intranet del Ayto. de Madrid



Veamos a modo de ejemplo el diseo de tablas implicadas en la gestin postal:

TABLA CMDT040
DESCRIPCIN Relacin entre codigos y poblaciones
CAMPO TIPO DE DATO ALMACEN OBSERVACIONES
NUMERO_POSTAL INTEGER NOT NULL RELATOR
CODIGO_PUEBLO INTEGER NOT NULL PUEBLO
CODIGO_POSTAL INTEGER NOT NULL AMBITO POSTAL
FECHA_ALTA DATE NOT NULL WITH DEFAULT FECHA CONTROL
HORA_ALTA TIME IDEM HORA CONTROL
USUARIO CHAR(8) IDEM USUARIO ALTA

VISTAS * NUMERO_POSTAL

CLAVE PRIMARIA NUMERO_POSTAL
NDICES NICO NUMERO_POSTAL
NO NICO COD_PUEBLO+COD_POSTAL
TABLA PADRE CMDT041 x NUMERO_POSTAL
CMDT042 x NUMERO_POSTAL

TABLA HIJA CMDT017 x COD_PUEBLO

TABLA CMDT042
DESCRIPCIN (POSTALES) Tramos propio y metropolitano
CAMPO TIPO DE
DATO
ALMACEN OBSERVACIONES
NUM_TRAMO INTEGER NOT NULL RELATOR
NUMERO_POSTAL INTEGER NOT NULL NUMERO
POSTAL
CODIGO_POSTAL INTEGER NOT NULL AMBITO POSTAL
SECCION_CARTERIA SMALLINT NOT NULL CARTERO
CODIGO_VIAL INTEGER NOT NULL VIA
TIPO_TRAMO CHAR(1) NOT NULL I,P,U
NOM_APP CHAR(3) NOT NULL NUM, KM, S/N
NUM_DESDE INTEGER NOT NULL NUMERO INI
CAL_DESDE CHAR(2) NOT NULL CALIFICADOR INI
NUM_HASTA INTEGER NOT NULL NUMERO FIN
CAL_HASTA CHAR(2) NOT NULL CALIFICADOR FIN
FECHAS ALTA/ACTU DATE/TIME NOT NULL WITH DEFAULT FECHAS(2)
CONTROL CONTROL ACT.
VISTAS * TRAMO_POSTAL
CLAVE PRIMARIA NUM_TRAMO
NDICES NICO NUM_TRAMO


NO NICO NUM_POSTAL + CODVIAL + TIP_TRAMO
NUM_POSTAL + SECCAR + CODVIAL +
TIP_TRAMO

TABLA PADRE

TABLA HIJA CMDT041 x NUM_POSTAL+SECCAR
CMDT040 x NUM_POSTAL

TABLA CMDT054
DESCRIPCIN (POSTALES) Tramos de viales nacin
COD_VIA_FIC INTEGER NOT NULL VIA NACION
COD_POSTAL INTEGER NOT NULL AMBITO POSTAL
TIPO_TRAMO CHAR(1) NOT NULL I,P,U
NUM_DESDE INTEGER NOT NULL NUMERO INI
NUM_HASTA INTEGER NOT NULL NUMERO FIN

VISTAS * TRAMO_POSTAL_NACION

CLAVE PRIMARIA COD_VIA_FIC,TIP_TRAMO,NUM_DESDE
NDICES NICO COD_VIA_FIC,TIP_TRAMO,NUM_DESDE

NO NICO
TABLA PADRE

TABLA HIJA CMDT053 x COD_VIA_FIC

TABLA CMDT068
DESCRIPCIN (POSTALES) Rutas de cambio reparto CAM
ID_RUTA INTEGER NOT NULL VIA NACION
COD_PUEBLO INTEGER NULL PUEBLO
COD_POSTAL INTEGER NOT NULL AMBITO POSTAL
NOM_PUEBLO INTEGER NULL PUEBLO
UNIDAD DESTINO INTEGER NOT NULL CORREOS UNID.
COD_POSTAL_UNID INTEGER NOT NULL AMBITO UNID.

VISTAS * ENRRUTAMIENTO_POSTAL


CLAVE PRIMARIA ID_RUTA
NDICES NICO
NO NICO COD_PUEBLO+COD_POSTAL
TABLA PADRE

TABLA HIJA CMDT017 x COD_PUEBLO

Los diseos fsicos de las tablas como vemos son diferenciados en funcin de
los tipos de datos necesarios y an cuando podramos haber establecido criterios de
unificacin por motivos de asepsia y actualizacin, as como de optimizacin en
accesos para aquellos datos ms utilizados se ha preferido el diseo especificado.
Vemos pues como el diseo lgico muchas veces debe de ser corregido de manera que
obtengamos los mejores resultados finales de nuestro nomencltor.

SQLSERVER. EL DISEO FSICO

Se mostrar aqu la descripcin de campos y forma de materializar los diseos
de nomencltores antes referidos. De esta manera el diseo se genera fsicamente en
el gestor elegido (en nuestro caso SqlServer). El modo de realizarlo ser prcticamente
idntico en todos los gestores. Para poder entender correctamente las sentencias que
detallamos deberemos de conocer algunas variables caractersticas de SqlServer, estas
son:
- ANSI_NULLS: En la versin 2012 por defecto ser ON. Hoy en da hay que
establecerlo, de manera que en ON especifica el comportamiento correcto de
acuerdo a ISO para los anlisis igual =, distinto <> al intervenir campos nulos.
Microsoft aconseja siempre ON, como es lgico.
- QUOTED_IDENTIFIER: Si est a ON se presupone el cumplimiento ISO en cuanto
al uso de delimilitadores de cadena e identificadores (comillas dobles [si est a
OFF se admitiran simples tambin]). El uso a OFF supone muchos problemas


entre otras el no poder usar en cadenas nombres reservados y problemas en la
creacin o modificacin de tablas. Se aconseja pues su uso siempre a ON.
- ANSI_PADDING: Controla el modo en el que la columna almacena datos ms
cortos que la longitud del campo para tipos char, varchar, binary y varbinary. En mi
caso me gusta siempre activarlo a ON. Es una operacin que se realiza en tiempo de
ejecucin, quedando almacenado el comportamiento para dichos campos. En la tabla
siguiente se especifica detalladamente el comportamiento de SqlServer para ambos
casos:

Configuracin
char(n) NOT NULL o
binary(n) NOT NULL
char(n) NULL o
binary(n) NULL
varchar(n) o varbinary(n)
ON
Rellena el valor original
(con espacios en blanco a
la derecha para las
columnas char y con
ceros a la derecha para
las columnas binary)
hasta completar la
longitud de la columna.
Sigue las mismas
reglas que para char(n)
o binary(n) NOT NULL
cuando SET
ANSI_PADDING es ON.
Los espacios en blanco a la derecha
en los valores de caracteres
insertados en las columnas varchar
no se recortan.Los ceros a la derecha
en los valores binarios insertados en
las columnas varbinary no se
recortan.Los valores no se rellenan
hasta completar la longitud de la
columna.
OFF
Rellena el valor original
(con espacios en blanco a
la derecha para las
columnas char y con
ceros a la derecha para
las columnas binary)
hasta completar la
longitud de la columna.
Sigue las mismas
reglas que para
varchar o varbinary
cuando SET
ANSI_PADDING es OFF.
Los espacios en blanco a la derecha
en los valores de carcter insertados
en una columna varchar se
recortan.Los ceros a la derecha en los
valores binarios insertados en una
columna varbinary se recortan.
(De la pgina web de Microsoft de SqlServer)

- CLUSTERED/NONCLUSTERED: Ya hablamos en el apartado de Conceptos
previos de este concepto. Efectivamente si el ndice es CLUSTERED es que se
trata de un ndice agrupado y si es NONCLUSTERED ser no agrupado. Por
defecto una PK (Primary key) ser siempre agrupada (salvo que ya exista otro
ndice agrupado) y un tipo de ndice UNIQUE ser no agrupado salvo que
especifiquemos lo contrario. Es conveniente usar nombres de ndices con
prefijo (en nuestro caso usamos PK y FK), de manera que podamos consultar la
tabla de ndices del sistema (select * from sysindexes where name like PK%)
atendiendo a los creados por nosotros.


- PAD_INDEX: Est relacionado con la generacin de ndices. En general lo
podremos a OFF para que el sistema maximice el espacio. El uso de ON ir
acompaado del mandato FILLFACTOR y requiere conocimientos superiores. Es
aconsejable el uso OFF.
- IGNORE_DUP_KEY: Est vinculado a ndices. El valor OFF producir un error al
incluir un valor ya existente, mientras que ON lo har solo de advertencia
(warning). Se aplica slo a los datos introducidos con posterioridad a la
creacin del ndice por lo que puede ser interesante a la hora de tener datos
previos con claves duplicadas, hecho que no queremos que vuelva a suceder en
adelante. En general tendr valor OFF.
- STATISTICS_NORECOMPUTE: A ON las estadsticas no se recalculan de forma
automtica. En general ser aconsejable el uso de estadsticas automticas
(valor OFF) ya que el optimizador de consultas est ntimamente ligado a las
estadsticas, de manera que pueden darse planes de accesos a datos
totalmente penalizados en tiempo. Muchas veces el no automatizar
estadsticas con cierta frecuencia incide sobre el rendimiento de la BBDD. Llega
un punto normalmente en el que la regeneracin hace que todo cambie. Lo
podemos hacer mediante un exec al procedimiento almacenado de SqlServer
denominado sp_updatestats (USE <nombre de la BBDD>; GO EXEC
sp_updatestats;) o bien si el problema de rendimiento lo est dando alguna
tabla en concreto mediante comandos del tipo UPDATE STATISTICS <nombre
de tabla> WITH FULLSCAN.
- ALLOW_ROWS_LOCK/ALLOW_PAGE_LOCK: Si se pone a ON (recomendado) se
admiten los bloqueos de filas y paginado de datos y adems ser el gestor el
que disponga cuando los precisa, caso contrario no habr bloqueos de ndice.
- CHECK_CONSTRAINT: Se utiliza para validar el contenido de un determinado
campo, normalmente a travs del contenido de otro de otra tabla en claves
forneas. Es un validador estupendo de cargas iniciales, aparte de un necesario
chequeo para la estabilidad de nuestro diseo con independencia de posibles
errores que podamos cometer en desarrollo de programacin.

Ahora ya podemos ver con tranquilidad como se implantara el diseo en
nuestro gestor concreto. Slo detallaremos las tablas bsicas de vial a numeracin del
nomencltor propio con el fin de no generar un exceso de pginas que poco nos
aportaran desde el punto de vista de nuestro estudio. He querido poner en negro lo
que sera el sql de la generacin de tabla y en azul la generacin de la vista. Se pueden
generar las vistas que se deseen de una tabla e incluso especificar los campos que se


quieren devolver (vista). En nuestro caso son selecciones del tipo Select *, por lo que
la totalidad de los campos se devolvern en las vistas generadas.

TABLA 001 (VIALES)
USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [BBDD].[TABLA_NUM_001](
[COD_VIA] [int] NOT NULL,
[COD_VIA5] [int] NULL,
[VIA_TIP] [nchar](1) NOT NULL,
[VIA_SIT] [nchar](1) NOT NULL,
[VIA_EST] [nchar](1) NOT NULL,
[FCH_PDE_VIA] [char](10) NULL,
[FCH_VIG_VIA] [char](10) NOT NULL,
[FCH_HIS_VIA] [char](10) NULL,
[COD_VIA_INICIO] [int] NULL,
[COD_VIA_FIN] [int] NULL,
[DEF_VIA] [char](1) NULL,
[FCH_RECEP_VIA] [char](10) NULL,
CONSTRAINT [PK_TABLA_NUM_001] PRIMARY KEY CLUSTERED
(
[COD_VIA] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[VIAL] as select * from BBDD.TABLA_NUM_001



TABLA 002 (CLASES DE VIALES)

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
[VIA_CLK] [smallint] NOT NULL,
[VIA_CLASE_TX] [nchar](24) NOT NULL,
[VIA_CLASE_ABREV] [nchar](5) NOT NULL,
[FCH_BAJ_CLS] [char](10) NULL,
(
[VIA_CLK] ASC
) ON [PRIMARY]
GO

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[CLASE] as select * from BBDD.TABLA_NUM_002

TABLA 003 (DENOMINACIONES DE VIALES)

USE [NOMENCLATOR]
GO
/****** Objeto: Table [BBDD].[TABLA_NUM_003]
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
[VIA_SQC] [smallint] NOT NULL,


[FCH_ALT] [char](10) NOT NULL,
[FCH_BAJ] [char](10) NULL,
[VIA_CLK] [smallint] NOT NULL,
[VIA_PAR] [nchar](6) NOT NULL,
[VIA_NOMBRE] [nchar](50) NOT NULL,
[VIA_NOMBREC] [nchar](25) NOT NULL,
[VIA_TIP_DENOM] [nchar](1) NOT NULL,
[VIA_OBSERVACIONES] [nvarchar](128) NOT NULL,
(
[COD_VIA] ASC,
[VIA_SQC] ASC
) ON [PRIMARY]
GO
GO
ALTER TABLE [BBDD].[TABLA_NUM_003] WITH CHECK ADD CONSTRAINT [FK_TABLA_NUM_003_TABLA_NUM_001]
FOREIGN KEY([COD_VIA])
REFERENCES [BBDD].[TABLA_NUM_001] ([COD_VIA])
GO
ALTER TABLE [BBDD].[TABLA_NUM_003] CHECK CONSTRAINT [FK_TABLA_NUM_003_TABLA_NUM_001]
GO
FOREIGN KEY([VIA_CLK])
REFERENCES [BBDD].[TABLA_NUM_002] ([VIA_CLK])
GO

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[DENOMINACIONES] as select * from BBDD.TABLA_NUM_003

TABLA 005 (DENOMINACIN DE NUMERACION DE VIALES)

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
[COD_APP] [int] NOT NULL,


[APP_NUM] [smallint] NOT NULL,
[APP_CLF] [nchar](2) NOT NULL,
[APP_CLS] [nchar](1) NOT NULL,
(
[COD_APP] ASC
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
CONSTRAINT [IX_TABLA_NUM_005] UNIQUE NONCLUSTERED
(
[COD_VIA] ASC,
[APP_NUM] ASC,
[APP_CLF] ASC,
[APP_CLS] ASC
ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
GO
GO
FOREIGN KEY([COD_VIA])
REFERENCES [BBDD].[TABLA_NUM_001] ([COD_VIA])
GO

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[APP] as select * from BBDD.TABLA_NUM_005

TABLA 006 (RELACIN ENTRE DENOMINACIN DE NUMERACIN VIALES Y POSICIN)

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
[COD_APP] [int] NOT NULL,
[COD_NDP] [int] NOT NULL,


(
[COD_APP] ASC,
[COD_NDP] ASC,
[FCH_ALT] ASC
) ON [PRIMARY]
GO
GO
FOREIGN KEY([COD_APP])
REFERENCES [BBDD].[TABLA_NUM_005] ([COD_APP])
GO
GO
FOREIGN KEY([COD_NDP])
REFERENCES [BBDD].[TABLA_NUM_007] ([COD_NDP])
GO

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[APP_NDP] as select * from BBDD.TABLA_NUM_006

TABLA 007 (POSICIN DE PORTAL)

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
[COD_NDP] [int] NOT NULL,
[NDP_TIP] [nchar](2) NOT NULL,
[COD_DISTRITO] [smallint] NOT NULL,
[COD_BARRIO] [smallint] NOT NULL,
[COD_CENSAL] [smallint] NOT NULL,
[COD_POSTAL] [int] NOT NULL,


[COD_EDIFICIO] [int] NULL,
[COD_PARCELA] [int] NULL,
[COD_SUBVIAL] [int] NULL,
[COORD_X] [int] NULL,
[COORD_Y] [int] NULL,
[ANGULO] [decimal](5, 2) NULL,
[PLANO_ACT] [nchar](1) NOT NULL,
(
[COD_NDP] ASC
) ON [PRIMARY]
GO
GO
FOREIGN KEY([COD_EDIFICIO])
REFERENCES [BBDD].[TABLA_NUM_008] ([COD_EDIFICIO])
GO
GO
FOREIGN KEY([COD_SUBVIAL])
REFERENCES [BBDD].[TABLA_NUM_009] ([COD_SUBVIAL])
GO

USE [NOMENCLATOR]
GO
SET ANSI_NULLS ON
GO
GO
create view [CMD].[NDP] as select * from BBDD.TABLA_NUM_007

Hemos visto hasta aqu como se materializara el diseo de nuestro esquema
concreto en base a las entidades y atributos definidos de nuestro diseo para una
implementacin SqlServer, de manera que nuestro diseo fsico habr quedado
completo y listo para ser cargado a travs de un bloque coherente de informacin:



BEGIN { TRAN | TRANSACTION }
[ { transaction_name | @INSERCCION_DATOS_PARCELA }
[ WITH MARK [ 'VUELTA_ATRAS_001' ] ]
]
<ORDENES SQL DE INSERCCIN>
[ ; ]

En el ejemplo anterior hemos definido una transaccin llamada
INSERCCION_DATOS_PARCELA en la que se incluiran todos los INSERT a la tabla y
con WITH MARK, lo que permitir al insertar la informacin realizar una vuelta atrs
hasta la marca INSERCCION_DATOS_PARCELA.

RELACIONES CON LA BBDD ESPACIAL

En el mbito estrictamente profesional slo me he tenido que enfrentar a BBDD
a travs del gestor espacial de ESRI. He utilizado diferentes BBDDEE, pero como
estudio personal y en estudios Universitarios. Este es uno de los inconvenientes de ser
S.I. pioneros del nomencltor, el que en aquel entonces no existan y ESRI fue pionera
en utilizar las BBDD relacionales para almacenar la informacin espacial que se
requera. As SDE como gestor espacial tiene acceso directo a la prctica totalidad de
gestores relacionales, pero siendo esta una ventaja debemos de considerar su alto
coste. En la actualidad las BBDD relacionales han venido incluyendo de forma
progresiva la posibilidad de tipos geography o geometry entre sus campos, con lo que
se abre una nueva perspectiva de cara a los nomencltores. Sinceramente pienso que
de aqu a algunos aos este mismo sistema que estamos analizando de gestores ver la
BBDD como un nico contenido incluyendo datos cartogrficos y alfanumricos en los
que el nomencltor podr fsicamente visualizarse como un todo y de hecho proyectos
nuevos as lo deben de ver y as estn surgiendo (idea en la que siempre he creido).



Oracle, DB2 en sus versiones espaciales y PostGIS estn bastante estudiadas, no
obstante SqlServer al ser relativamente reciente no. Es por ello y porque estamos
analizando una BBDD relacional en SqlServer por lo que creemos necesario en este
apartado ver algunos fundamentos bsicos de dicho gestor con respecto a los datos
espaciales para luego resear como estamos realizando actualmente las tareas a
travs de SDE en dicho sistema pero en su versin 2005.

La versin 2008 (que no la 2005) ya incluye la posibilidad de tipos espaciales,
con lo que simplemente una migracin podra iniciar un proceso en el que el
tratamiento espacial se realizar directamente mediante programacin a travs de
SSQL (modo en que se suelen referir los textos al Spatial SQL).

SqlServer admite dos tipos de datos geography referido a sistemas de
coordenadas geogrficos y geometry referido a sistemas de coordenadas
transformados a plano. Los objetos admitidos dentro de cada uno de estos tipos son
los siguientes, que podemos ver en la siguiente figura:

Objetos de tipos de datos espaciales admisibles en SqlServer 2008 (Fte: Microsoft)



La indexacin de estos campos no puede realizarse con la conocida tecnologa
B-tree de campos alfanumricos. Los datos espaciales se indexan en base a MBR
(Minimum bounding rectangle) realizados en base a tecnologa R-tree y QuadTree, de
las que derivan otras como GiST (Generalized Search Tree usada por los
desarrolladores de PostGIS).

Esquema de indexacin R-tree de elementos espaciales en una BBDD relacional

SqlServer utiliza cuatro niveles de teselas de igual nmero de filas que de
columnas de MBR con independencia del tipo de dato usado.



La identificacin numrica de teselas se hace siguiendo teora de fractales, de
manera que se utiliza el espacio de Hilbert (como sabemos una generalizacin del
espacio Eucldeo) y utilizando el orden establecido por la llamada curva de Hilbert que
recorre en una nica polilnea los centros de las direntes divisiones teselares. En
realidad SqlServer dice utilizar una variacin del orden de esta curva, pero no nos
especifica con exactitud en qu vara respecto al diseo matemtico conocido.

Ejemplo de generacin de curvas de Hilbert de ordenes 1,2 y 3. Fte.- Jos Olarrea Busto (UPM)

Cuando a travs de T-SQL (Transaction SQL) realicemos un CREATE SPATIAL
INDEX la clausula no necesaria GRID nos permitir modificar el tamao de tesela. Los
valores permitidos para GRID son LOW (4x4 celdas), MEDIUM (8x8) y HIGH(16x16). El
valor por defecto es MEDIUM.

Despus de realizar la divisin MBR, SqlServer realiza lo que denominan
teselacin de objetos, de manera que cada objeto se adapta a aquel nivel de teselacin
en el que pueda entrar aplicando ciertas normas de forma recursiva para cada uno de
los cuatro niveles. Las normas que SqlServer usa son (Fte: Microsoft):

- La regla de cobertura
Si el objeto cubre una celda por completo, se dice que dicha celda est cubierta
por el objeto.Se cuenta una celda cubierta y no se aplica la teselacin.Esta regla
se aplica a todos los niveles de la jerarqua de cuadrculas.La regla de cobertura


simplifica el proceso de teselacin y reduce la cantidad de datos que un ndice
espacial registra.
- La regla de celdas por proyecto
Esta regla exige el lmite de celdas por proyecto, que determina el nmero
mximo de celdas que se pueden contar para cada objeto, excepto en el nivel
1.En los niveles inferiores, la regla de celdas por proyecto controla la cantidad
de informacin que se puede grabar sobre el objeto.
- La regla de celda ms profunda
La regla de celda ms profunda genera la mejor aproximacin de un objeto
grabando solo las nicas celdas de la parte ms inferior que se han teselado
para el objeto.Las celdas principales no contribuyen al recuento de celdas por
objeto y no se graban en el ndice.

Veamos un posible ejemplo de generacin de una tabla SqlServer con ndice
espacial, asignando una superficie de edificacin a los portales:

CREATE TABLE PORTALES
(
ID_OBJETO INT IDENTITY(40000000,10) NOT NULL,
NOM_APP_ASOCIADA VARCHAR(100) NOT NULL,
GEOM GEOMETRY NOT NULL
)

Vemos que hemos creado la tabla PORTALES con un campo autoincremental
entero que comenzar por el nmero 40MM y se autoincrementar de 10 en 10, un
campo que contendr el literal que asignemos al portal NOM_APP y un campo
geometra en proyeccin (GEOMETRY). Ahora veremos como a travs de T-SQL
podemos insertar un par de polgonos en dicha tabla:

DECLARE @poligono1 geometry
DECLARE @poligono2 geometry
SET @poligono1 = 'POLYGON((10 10, 40 10, 40 40, 10 40, 10 10))'
SET @poligono2 = 'POLYGON((30 30, 50 30, 50 50, 30 50, 30 30))'


INSERT INTO PORTALES
(NOM_APP,GEOM) VALUES ('C/ UNO n 7,@poligono1)
INSERT INTO PORTALES
(NOM_APP,GEOM) VALUES ('C/ DOS n 8',@poligono2)

Y podremos realizar consultas sobre dichos datos con uno de los mtodos para
ello establecidos:

SELECT NOM_APP, GEOM.STArea() FROM PORTALES

A continuacin se detallan todas las funciones disponibles para SqlServer
Spatial en el momento actual:

GEOGRAPHY GEOMETRY Denali
CTP
Minimum DB
Compatibility
Level
OGC Methods
STArea() STArea() 100
STAsBinary() STAsBinary() 100
STAsText() STAsText() 100
STBoundary() 100
STBuffer() STBuffer() 100
see EnvelopeCenter() STCentroid() 100
STContains() STContains() CTP1 100
STConvexHull() STConvexHull() CTP1 100
STCrosses() 100
STCurveN() STCurveN() CTP1 110
STCurveToLine() STCurveToLine() CTP1 110
STDifference() STDifference() 100
STDimension() STDimension() 100
STDisjoint() STDisjoint() 100
STDistance() STDistance() 100
STEndPoint() STEndPoint() 100
see EnvelopeAggregate() STEnvelope() 100
STEquals() STEquals() 100
na STExteriorRing() 100


STGeometryN() STGeometryN() 100
STGeometryType() STGeometryType() 100
na STInteriorRingN() 100
STIntersections() STIntersections() 100
STIntersects() STIntersects() 100
STIsClosed() STIsClosed() 100
STIsEmpty() STIsEmpty() 100
na STIsRing() 100
STIsSimple() 100
STIsValid() STIsValid() CTP1 100
STLength() STLength() 100
STNumCurves() STNumCurves() CTP1 110
STNumGeometries() STNumGeometries() 100
na STNumInteriorRing() 100
STNumPoints() STNumPoints() 100
STOverlaps() STOverlaps() CTP1 100
STPointN() STPointN() 100
STPointOnSurface() 100
STRelate() 100
STSrid STSrid 100
STStartPoint() STStartPoint() 100
STSymDifference() STSymDifference() 100
STTouches() 100
STUnion() STUnion() 100
STWithin() STWithin() CTP1 100
na STX() 100
na STY() 100
Extended Methods
AsBinaryZM() AsBinaryZM() CTP3 110
AsGML() AsGML() 100
ASTextZM() ASTextZM() 100
BufferWithCurves() BufferWithCurves() CTP1 110
BufferWithTolerance() BufferWithTolerance() 100
CurveToLineWithTolerance() CurveToLineWithTolerance() CTP1 110
EnvelopeAngle() na 100
EnvelopeCenter() na 100
Filter() Filter() 100
HasM HasM CTP3 100
HasZ HasZ CTP3 100
InstanceOf() InstanceOf() 100
IsNull() IsNull() 100
IsValidDetailed() IsValidDetailed() CTP3 100
Lat() na 100


Long() na 100
M() M() 100
MakeValid() MakeValid() CTP1 100
MinDbCompatibilityLevel() MinDbCompatibilityLevel() CTP1 100
Reduce() Reduce() 100
ReorientObject() na CTP1 100
NumRings() na 100
RingN() na 100
ShortestLineTo() ShortestLineTo() CTP1 100
ToString() ToString() 100
Z() Z() 100
STGeomCollFromText() STGeomCollFromText() 100
STGeomFromText() STGeomFromText() 100
STLineFromText() STLineFromText() 100
STPointFromText() STPointFromText() 100
STPolyFromText() STPolyFromText() 100
STMLineFromText() STMLineFromText() 100
STMPointFromText() STMPointFromText() 100
STMPolyFromText() STMPolyFromText() 100
STGeomCollFromWKB() STGeomCollFromWKB() 100
STGeomFromWKB() STGeomFromWKB() 100
STLineFromWKB() STLineFromWKB() 100
STPointFromWKB() STPointFromWKB() 100
STPolyFromWKB() STPolyFromWKB() 100
STMLineFromWKB() STMLineFromWKB() 100
STMPointFromWKB() STMPointFromWKB() 100
STMPolyFromWKB() STMPolyFromWKB() 100
Extended Static Methods
GeomFromGML() GeomFromGML() 100
Parse() Parse() 100
Point() Point() 100
Null() Null() 100
Aggregates (Extended Static Methods)
CollectionAggregate() CollectionAggregate() CTP1 100
ConvexHullAggregate() ConvexHullAggregate() CTP1 100
EnvelopeAggregate() EnvelopeAggregate() CTP1 100
UnionAggregate() UnionAggregate() CTP1 100
Mtodos espaciales disponibles en SqlServer 2012. Todos las sintaxis que comienzan por ST cumplen los
estndares OGC Fte Microsoft.



Todas ellas utilizables, por ejemplo con Microsoft.SqlServer.Types.dll o
NETopologysuite si usamos C# o bien a travs de Topology suite si usamos java.

Ahora veremos la manera de crear tablas en SqlServer desde SDE, ya que hasta
el momento actual es la que usa el Ayuntamiento de Madrid para integrar en el
nomencltor datos espaciales, perteneciendo en realidad al diseo combinado BDC y
SIGMA. Lo normal es utilizar Arc-Catalog para este tipo de operacin. El proceso es
sumamente sencillo con la herramienta, de manera que tampoco entraremos en
descripciones paso a paso. La ligazn entre tablas Sqlserver y SDE si son espaciales
siempre se deben de crear desde SDE, por ello utilizaremos el nombre de servidor de la
BBDDEE en la que se encuentra la dicha BBDDEE y en la que vayamos a incluir nuestra
tabla espacial, acompaado del concepto instancia SDE. Necesitaremos permisos
especiales dados a travs del password de Administrador u otros que estn
autorizados para ello. Una tabla espacial en sde se define como del tipo SDE FEATURE
CLASS y la geometra (GEOMETRY) podr ser cualesquiera de las admitidas, por
ejemplo POINTS. En la imagen podemos ver la ventana de Arc-Catalog en la que hemos
definido una tabla (en este caso la tabla de transportes del municipio) que combina
estaciones y accesos.

Tabla SDE conteniendo accesos y estaciones de Madrid



Aunque es ms cmodo realizar la operacin de creacin de una tabla desde la
herramienta ESRI Arc-Catalog, no podemos olvidar que esta misma operacin se puede
realizar por administracin en lnea de comandos o con ficheros por lotes (BAT)
preparados al efecto a partir del tratamiento %1,%2 como parmetros de nuestro
lote que representar campos y tipos, por ejemplo. Si la tabla no tiene contenido
espacial, se podr crear con el primer comando, mientras que si tiene contenido
espacial, requeriremos realizar dos pasos (sdetable+sdelayer):

sdetable -o create -t <table> -d <column_definition> [-k <config_keyword>] [-i
<service>][-s <server_name>] [-D <database>]-u <DB_User_name> [-p
<DB_User_password>] [-q]

y despus para integrar la componente espacial:

sdelayer -o add -l <table,column> -e <entity_mask>[Spatial_Index] [{-R <SRID>
| [Spatial_Ref_Opts]}]
[-M <minimum_id>] [{-f <init_features,avg_points> | -k <config_keyword>}][-
E <{empty | xmin,ymin,xmax,ymax}>] [-t <storage_type>][-L {ON | OFF}] [-C
<row_id_column>[,{SDE|USER}[,<min_ID>]]][-P {32 | 64}] [-S
<layer_description_str>] [-i <service>]
[-s <server_name>] [-D <database>] -u <DB_User_name>[-p
<DB_User_password>] [-q]

Por defecto al crear una tabla mediante comandos la tabla es de versin por
defecto, pero si queremos poder editarla por ejemplo a travs de ArcGis-Desktop,
debera ser multiversionada, para lo que utilizaremos el comando $ sdetable -o
alter_reg con la opcin V multi.

Debemos de tener cuidado a la hora de consultar registros desde SqlServer (o
cualquier otro gestor en el que se apoye SDE) debido a que SDE utiliza mecanismos de


consolidacin propios. En un momento dado una select sobre SqlServer no dar los
mismos resultados que si la hacemos a travs de SDE, siendo la de este ltimo gestor
espacial la correcta. Efectivamente SDE maneja versiones en la edicin o tratamiento
de informacin, lo cual representa numerosas ventajas, pero tambin algn
inconveniente. Esta informacin versionada se almacena en las llamadas tablas DELTA,
de manera que tendremos una tabla A de altas y una tabla llamada D de bajas para
cada versin. As, hasta que no se cierra el versionado no se visualizar correctamente
la informacin mediante SDE, sin embargo y aunque SDE no consolide, realiza
interpretaciones correctas y las respuestas proporcionadas resultan ciertas, pero no
tendr porqu ser as sobre el gestor soporte (SqlServer, Oracle)

Esquema de operaciones sobre una tabla SDE antes y despus de realizar la compresin (Fte: ESRI)

El medio que tenemos para consolidar totalmente y eliminar las tablas DELTA
de cada versionado es utilizar en administracin el comando:



sdeversion -o compress [-N] -u <DB_user_name> [-p <DB_User_password>] [-q]
[-i <service>] [-s <server_name>] [-D <database>]

Es absolutamente necesario ejecutar este commando siempre y cuando
tengamos que utilizar directamente informacin sobre el gestor soporte (SqlServer,
Oracle, PostGreSQL). Adems es lo primero que haremos ante sntomas de cansancio
de la BBDDEE (si las estadsticas consolidan una BBDD, la compresin lo hace en SDE).
El efecto que producir este comando es el siguiente:

- Eliminar los estados de versionados sin referencias y los registros de sus tablas
DELTA asociadas.
- Mover los datos de las tablas DELTA comunes a todas las versiones a la tabla
propia SDE (base table segn la nomenclatura ESRI).
- SDE ya no tendr que recorrerse las versiones DELTA para cada consulta, de
manera que ahora slo lo deber hacer sobre la tabla propia de SDE (base
table), de manera que la minimizacin de datos y el tener que buscar en una
sola tabla mejora el rendimiento en general.

El tratamiento de versionados desde cdigo se podr realizar usando la
siguiente clase java suministrada por ESRI para manejar tablas multiversionadas:

http://www.google.es/url?sa=t&rct=j&q=createchildstate%20sde&source=web&cd=1
&ved=0CDUQFjAA&url=http%3A%2F%2Fhelp.arcgis.com%2Fen%2Fgeodatabase%2F10
.0%2Fsdk%2Farcsde%2Fsamples%2Fcom%2Fesri%2Fsde%2Fdevhelp%2Fversioning%2F
VersioningExample1.java&ei=2mbcUJ_rBoOmhAfLk4HoBA&usg=AFQjCNFAe6VqYze10
uBSM6fN46O483NLGg

Es recomendable y asptico el programar de cara a la administracin SDE la
compresin peridica de tablas, pues de lo contrario nos podemos encontrar con que
dicha compresin tardar horas, en vez de segundos o algn minuto.


Ya que hemos hablado de estadsticas, decir que las estadsticas sobre tablas
tambin se pueden realizar sobre SDE en funcin del gestor desde administracin, con
el siguiente comando en lnea:

Oracle:
sdetable -o update_dbms_stats -t <table_name> [ -K <keyword>]
-m <{estimate | compute}>
[-n <{ALL | <index_name>}>] [-i <service>] [-s <server_name>][-D <database>]
[-u <DB_User_name>] [-p <DB_User_password>] [-N] [-q]

SQL Server:
sdetable -o update_dbms_stats -t <table_name> [ -K <keyword>]
-m <"{with fullscan | with sample %% percent} [index]"> [-i <service>]
[-s <server_name>] [-D <database>] [-u <DB_User_name>]
[-p <DB_User_password>] [-N] [-q]

DB2:
sdetable -o update_dbms_stats -t <table_name> [-K <keyword>]
[-n {ALL | <index_name>}] [-m <{dbms options}>]
[-i <service>] [-s <server_name>] [-D <database>]
-u <DB_User_name> [-p <DB_User_password>] [-N] [-q]

As, nuestra tabla ya estar lista para ser usada a travs de las herramientas
ESRI, o lo que ser ms frecuente para nuestro nomencltor: A travs de
programacin. Veamos un ejemplo de conexin a nuestra tabla:



package pruebaConexionSDE;

import com.esri.sde.sdk.client.SeConnection;
import com.esri.sde.sdk.client.SeDelete;
import com.esri.sde.sdk.client.SeException;
import com.esri.sde.sdk.client.SeLayer;
import com.esri.sde.sdk.client.SeObjectId;
import com.esri.sde.sdk.client.SeState;
import com.esri.sde.sdk.client.SeVersion;

public class conexionSDE {

public static void main (String args[])throws Exception {
SeConnection conn = null;
String server = "10.90.XX.XX";
int instance = 51XX;
String database = "NOMENCLATOR_ESPACIAL ";
String user = "USUARIO_AUTORIZADO";
String password = "PASSWORD_USUARIO_AUTORIZADO";
try {
conn = new SeConnection(server, instance, database, user, password);
System.out.println ("Conexin realizada a : "+ server + " ... ok");
conn.close();
}
catch (SeException e) {
}
}
}
Ejemplo de conexin SDE a la base de datos que posibilita accede a cualquier tabla

En el caso de la BDC de Madrid, actualmente las tablas mantenidas y
gestionadas de forma directa del GIS por el nomencltor son las siguientes:

- Tabla del seccionado censal del municipio (mantenimiento-gestin)
- Tabla de las numeraciones de portales de la ciudad (carga-actualizacin)
- Tabla de gestin de ndices fiscales del Ayuntamiento (mantenimiento-gestin)
- Tabla de transportes del CTM (carga-actualizacin)

Otras tablas usadas en su componente espacial por BDC, aunque no
dependientes directamente de ella son:

- Tabla de parcelas catastrales del municipio
- Tabla de subtramos de vial y acera del Ayuntamiento
- Tabla de distritos y barrios



Como sabemos la componente espacial hace que el nomencltor pueda realizar
preguntas que hasta ahora eran complicadas. Por ejemplo si un inspector de va
pblica ha detectado una rotura en una tapa de alcantarilla y se comunica la posicin
GPS, el tcnico municipal podr preguntar a BDC: Es en acera o en calzada?, de
manera que as se sabr si afecta al trfico rodado o no, lo cual en determinadas calles
es crucial. Por otro lado si est en acera puede resultar altamente peligroso para los
viandantes Hasta ahora esa pregunta ahora inmediata tena que ser comunicada de
otra manera. Adems podr conocerse la empresa concesionaria de mantenimiento y
hacer una comunicacin telemtica inmediata con el informe del tcnico municipal en
su caso. Es evidente que la componente espacial ser cada da ms utilizada en los
futuros nomencltores, lo cual es sumamente aconsejable de cara a una
Administracin eficaz.

MODELADO INSPIRE

En INSPIRE (Infrastucture for Spatial Information in Europe) se establecen las
normas cuyo objetivo ltimo es la creacin de una Infraestructura de Informacin
Espacial en la Comunidad Europea basada en la de cada uno de los Estados
pertenecientes a la UE. Estas normas se aprobaron por el Parlamento Europeo
entraron en vigor el da 25 de abril de 2007. Se pretende poner a disposicin I.G.
relevante y de calidad de forma que sirva a los procesos de desarrollo de la propia
Unin. Con el fin de no perdernos en el mbito de lo puramente legal, su desarrollo en
Espaa queda reflejado en la LISIGE (Ley 14/2010, de 5 de julio, sobre las
infraestructuras y los servicios de informacin geogrfica en Espaa). El verdadero quid
de la cuestin es que la directiva exige que las normas de ejecucin (implementing
rules) en cuanto a metadatos (se pueden validar en:
http://inspire-
geoportal.ec.europa.eu/validator2/
)( o editar en:
http://inspire-geoportal.ec.europa.eu/editor/
),
especificacin de datos, servicios de red, servicios de datos espaciales, datos y
servicios de uso compartido y seguimiento e informes sean compatibles e
interoperables y al ser Reglamentos de la Comisin Europea son de obligado
cumplimiento.


Con el fin de facilitar la labor, la Comisin ha facilitado las denominadas guas
tcnicas de directrices (technical guidelines). Adems para el caso que nos ocupa de
los nomencltor se cre el proyecto EURADIN que ha durado dos aos y ha finalizado
en Junio de 2010, cuyo objetivo principal era conseguir la interoperabilidad de
direcciones, contribuir a su armonizacin en la UE y promover la creacin de servicios
de alto valor aadido en Europa y que tambin ha servido para crear la EAF (European
Address Forum) configurada como una eNETWORK de continuidad del proyecto
EURADIN en forma de foro telemtico. Tambin se ha desarrollado el foro de
direcciones de Espaa y el foro ibrico de direcciones.

En el marco del Real Decreto 1495/2011, de 24 de octubre, por el que se
desarrolla la Ley 37/2007, de 16 de noviembre, sobre reutilizacin de la informacin
del sector pblico, para el mbito del sector estatal tambin tenemos que enmarcar el
programa AVANZA2 el cual debe de afectar a los Ayuntamientos y basar los criterios de
direcciones en base a la normativa INSPIRE.

El primer problema que se nos presenta como responsables del nomencltor
municipal es responde el modelo INSPIRE a todas las necesidades municipales?, dicho
de otra manera: podemos pues abandonar el modelo previo y decantarnos por el
modelo INSPIRE? La respuesta en el caso de un gran municipio con las caractersticas
vistas para una gran AALL es que no, de modo que al ser necesaria la adaptacin a
INSPIRE nos encontramos ante una alternativa triple:

-
Iniciar el proyecto de adaptacin INSPIRE como un todo.
-
Ver si el modelo INSPIRE es adaptable como parte de nuestro todo.
-
Generar un modelo INSPIRE independiente y actualizado permanentemente

El primero de ellos es ms bien factible para pequeos municipios u otros que
no tengan las caractersticas ampliadas del caso de Madrid. El segundo es una buena
opcin y es el que ha sido adoptado, o lo est siendo por organismos como el IGME
(Instituto Geolgico y Minero de Espaa), mientras que el tercero tambin constituye


una buena opcin pues su regeneracin desde el punto de vista del diseo de BBDD de
Madrid es simple, de fcil implementacin y no altera la buena gestin de lo existente.

El diseo para direcciones de INPIRE es el mostrado aqu:



Desde un punto de vista prctico veamos a que corresponde cada entidad:



Veamos tambin los elementos principales de manera que podamos entender el
diseo necesario para INSPIRE. Comencemos por los viales:

En cuanto a direcciones postales aunque hay posibilidad de meter el PostName,
en nuestro sistema postal no tiene demasiado sentido, aunque podra especificarse en
l cierto nombre de inters, pero en general ir vaco, rellenndose tan slo el campo
correspondiente a Postcode. Por otra parte para los portales y locales tendremos un
esquema como el de la figura (****)

El DataType Geographical Position, aunque no lo hemos destacado es
obligatorio en INSPIRE y representa la posicin puntual de una direccin concreta. En
GeometricMethodValue se especifica el tipo de geometra [punto (la habitual),
derivada de la geometra de una va (desplazamiento en), o bien derivada de la
geometra de un trmino municipal u otro lmite adminsitrativo]. Una direccin en
INSPIRE puede tener varias posiciones geomtricas, de manera que si esto es as, se


deber rellenar el campo GeometrySpecificationValue (portal y colegio electoral, por
ejemplo, si deseamos asociar la posicin del portal tambin a la referencia de voto).

Especificacin entidad LOCATOR - Fte- Alicia Gonzalez Jimenez (I.G.N.) Miembro TWG-AD (****)

En cuanto a las Unidades Administrativas, el nivel a tener en cuenta viene ya
marcado por INSPIRE para cada pas. As tenemos:



Niveles (level) para las entidades AdminUnitName Fte: Portal INSPIRE

Por ltimo la entidad AdressRepresentation es una entidad que representa
simplificadamente una direccin. Datos simplificados e inmediatos de una direccin.



Vemos pues que la alternativa de generar una BBDDEE acorde con INSPIRE del
modelado Adress es relativamente simple desde un modelo ms complejo como el
que ya vimos para el caso particular del municipio de Madrid. Ese modelo ser el que
segn la propia directiva haya que poner a disposicin y sobre l crear los servicios
oportunos para garantizar la interoperabilidad deseada.

Resumen del campo/tabla para distintas direcciones-tipo europeas Fte: INSPIRE UE
(
http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/INSPIRE_DataSpecification_AD_v2.0.pdf
)



SERVICIOS IDEE

Dentro de los servicios IDEE tambin deberemos de cumplir, si el proyecto es
nuevo con la directiva INSPIRE, ya que son directivas europeas, que como decimos
deben ser cumplidas. Los servicios IDEE que no pueden faltar en un nomencltor a mi
entender son dos: WMS y Gazetteer. Otros servicios que pueden resultar de inters
dependiendo muchas veces de los servicios que haya que prestar y los datos asociados
a nuestro nomencltor y de responsabilidad propia son:

- WFS: Permite acceder, recuperar y modificar datos espaciales en formato
vectorial almacenados en servidores remotos. Hay tres tipos: Bsico, XLINK y
WFS-T.
- WCS: Datos de cobertura con los valores del fenmeno en cada posicin que
permiten realizar interpretaciones e interpolaciones con dichos datos.
- WCTS: Permite transformar o convertir las coordenadas de un conjunto de
entidades entre dos Sistemas de Referencia Espacial.
- CWS: Publicacin y el acceso a catlogos digitales de metadatos para datos y
servicios geoespaciales (Para la generacin de metadatos es interesante la
herramienta gratuita CatMdEDIT).
- WTS: Servicio de generacin de vistas en perspectiva de una zona determinada.
- SWE: Explotacin de sensores conectados a travs de la Web.
- SML: Localizacin, el anlisis y procesamiento de las observaciones.

Como hemos dicho centraremos nuestro estudio en los dos bsicos que
creemos debe de tener cualquier Administracin Local de gran tamao.



SERVICIO GAZEETTER

Como cualquier servicio web WFS-G necesitar un documento XML de envo
con una estructura definida, de manera que responder devolviendo una o ms
entidades de respuesta a travs de la red.

Esquema de algunas operaciones OGC a las que debe responder un WFS-G Fte: Compusult Limited

Un servicio de nomencltor de acuerdo a las premisas OGC deber de disponer de las
siguientes operaciones:
- GetCapabilities: Informacin de metadatos del servicio, los tipos de fenmenos
(features) que se devuelven y las operaciones posibles para cada tipo de
features.
- DescribeFeatureType: Descripcin de la estructura de tipo de fenmeno
solicitado.
- GetFeature: Devolucin del fenmeno en formato GML.
- GetGmlObject: Devolucin del fenmeno en base a su identificador nico en
formato GML.



Es complicado encontrar plataformas de ayuda para la implantacin de este
tipo de servicios. Degree parece el software de publicacin que parece ms avanzado y
amigable en este sentido (Con Deegree 2.3 se consiguen estndares del tipo OGC WFS
1.1.0 y descarga de ficheros GML 3.2.1 de acuerdo al modelo de datos de INSPIRE),
pero en nuestro caso no hemos implementado un servicio de estas caractersticas, al
menos por el momento en el mbito del municipio de Madrid.

Actualmente creemos que un servicio Gazeetter resulta til para el callejero de
la ciudad de Madrid, con el fin de que otras aplicaciones lo usen en pro de una mejora
de la informacin y como servicio de los mltiples usuarios que lo utilizarn. Pensamos
en un cadena de informacin, a la que realizando la oportuna segmentacin y
ponderando las distintas distancias semnticas con respecto a fonos-grafos
establecidos diera unos inmejorables resultados con respecto a Gazeetter generalistas.
Esperamos poderlo abordar como diseo propio en breve.

El Ayuntamiento de Madrid dispone de un esquema de infraestructura tecnolgica de cara a la
prestacin de servicios web adecuado Fte (Ayuntamiento de Madrid)


Actualmente hay disponible un servicio web (utilizado en el aplicativo ejemplo
al final de este trabajo) que no tiene el enfoque de un Gazetter propiamente dicho,
aunque se parece mucho. En el caso del WebService de BDC, la funcionalidad (dispone
de otras muchas, como cercana de informacin o un plano de tamao especificado de
una zona, obtenido a travs de la llamada a servicios IMS de ArcGis) est enfocada a
una validacin correcta de informacin, de manera que mediante codificaciones
parciales en estados de la informacin, el usuario recorriendo el esquema puede
identificar que es lo que tiene que presentar al usuario y as la mejora de la
informacin se produce en fases y no en bloque como hara un Gazetteer puro.
Las herramientas de generacin de servicio web generan ficheros de esquema
llamados XSD (los que suele proporcionar OGC como documentacin) y ficheros XML
denominados concretamente WSDL (Web Services Description Language) que pueden
ser invocados remotamente, de manera que en la actualidad todos los paquetes de
desarrollo posibilitan el manejo inmediato del objeto a travs de dicha descripcin
WSDL de forma cmoda (ver ejemplo de uso de wsdl en la documentacin del ejemplo
de visualizados histrico al final de este estudio).

El WSDL que define el servicio web municipal es:
http://www-2.munimadrid.es/WSValidacionBDC/services/WSValidacionBDC/wsdl/WSValidacionBDC.wsdl

Como vemos el mismo es capaz de atender a las siguientes peticiones:
- getImageMapa
- getNumerosCercanos
- traducirDireccion
- validarDireccion

Los servicios web municipales no admiten altas (obtencin) al nomencltor a
travs de un servicio web, no obstante esto se podra llegar a realizar a travs de un
doble filtro usuario autorizado municipal ms firma electrnica usando el producto


SIAVAL o cualquier otro debidamente certificado por el Centro Criptolgico Nacional (
https://www.ccn.cni.es/ ).

SERVICIO DE MAPAS

Un Servicio de publicacin de mapas (WMS) es una interfaz web que permite
extraer mapas dinmicamente, como imagen a partir de informacin geogrfica, ya
sea vectorial o rster y que gestionar el servidor conforme a los criterios del usuario y
estndares OGC. Las operaciones que debe permitir un WMS son las siguientes (OGC
identifica las dos primeras como obligatorias)

- GetCapabilities: Metadatos del servicio en los que adems se informa de las
caractersticas de los mapas que pueden ser servidos o producidos.
- GetMap: Devuelve un mapa en formato imagen de los datos que han sido
solicitados el usuario.
- GetFeatureInfo: Informacin alfanumrica sobre contenidos del mapa, tal
como, el valor de un objeto que est en una posicin dada.

El Ayuntamiento de Madrid tiene publicado un servicio de mapas en la
siguiente direccin:

http://www-2.munimadrid.es/wmsconnector/com.esri.wms.Esrimap/SIGMA2005_WMS_INV

que ofrece las opciones GetCapabilities, GetMap y GetFeatureInfo, no obstante este
servicio ser renovado en breve al tener nueva disponibilidad de cartografa. Adems
existan problemas en la anterior versin de muy diversa ndole. En SIGMA, que es la
aplicacin proveedora del WMS (parte cartogrfica del nomencltor), se realizar la
publicacin a travs de ArcGis Server, lo cual es sumamente sencillo, pues bsicamente
hay que crear un documento de mapa (.mxd) vaco y despus abrirlo con ArcMap. A
partir de ese momento los pasos son:


- En la barra de herramientas activar publicacin de servicio de mapas
- Pulsar la opcin analizar
- Aparecen errores que habr que subsanar en su totalidad, pudiendo hacer
vista previa en todo momento para ver cmo evoluciona la resolucin de
errores.
- Una vez que todos los errores han sido corregidos pulsaremos la opcin
publicar
- Se selecciona el servidor, los recursos y servicios y se pulsa finalizar

Es importante saber que el servicio lo podemos crear en cualquier equipo
(desarrollo, por ejemplo), pero el fichero de servicio de mapas (.msd) generado
deberemos de copiarlo en el directorio de entrada del servidor que realmente va a
servir el WMS. Aunque existe la posibilidad de generar la publicacin del servicio desde
ArcCatalog navegando hasta el fichero .mxd, esto no es aconsejable, pues el
rendimiento de ese WMS ser sensiblemente inferior y restar toda la operatividad y
desempeo que los usuarios esperan de l. Lo anterior es as porque a partir de la
versin ArcGIS Server 9.3.1., ESRI ha introducido el concepto de servicio de mapas
optimizado que usa nuevas funcionalidades de dibujo rpido que slo es posible
obtener a travs de la publicacin del servicio de mapas mediante el asistente de
ArcMap, permitiendo usar los ficheros msd, en vez de los obsoletos (como servicio de
mapas) mxd. Adems en cualquier caso es ms que aconsejable crear memorias cache
de mapas sobre el servicio creado para dar una respuesta dinmica realmente potente
gracias a una generacin de cach en base a modelos de teselacin, dispongamos del
msd y toda su potencia o tan slo del mxd. Hemos de decir tambin que el uso de msd
posibilita un uso intensivo de algoritmos que evitan el antialiasing.

El antialiasing es un efecto perverso que se produce en las pantallas de
ordenador cuando queremos representar en una serie de pixeles concretos una
informacin de frecuencia muy elevada, lo que provoca efectos de visualizacin
errneos, lo cual tambin mejorar la calidad del servicio WMS. Con mxd esto no
siempre es posible o adems nunca a la velocidad que lo realiza un msd.



Personalmente soy un gran defensor de la publicacin de servicios a travs de
plataformas GPL, por ello en este caso, adems de haber explicado sucintamente la
manera de realizar una publicacin con ArcGis Server, tambin vamos a publicar desde
GeoServer. Vamos a ver un ejemplo paso a paso de cmo podramos realizar esta
operacin.

Con antialiasing y corregido su efecto en una imagen de ordenador - Fte: compegps web

Vamos a verlo de dos maneras diferenciadas. Por una parte podemos tener una
extraccin de cartografa en formato shape, que puedes ser la que queramos
independizar de los datos de trabajo de cara al servicio o bien podemos atacar
directamente a nuestras tablas de SDE. Veamos como incorporar los datos en ambos
casos:

Dentro de Geosuite, supongamos que partimos de los shapes que tenemos (en
mi caso un pequeo extracto de datos cartogrficos referentes al municipio de
COSLADA)



Una vez arrancado el servicio con Geosuite podremos acceder a este servicio a
travs de la pestaa Getting Started y ya veremos las distintas opciones que nos
interesan:

(Pestaa Getting Started)

Tambin podramos acceder a travs de Components->Geoserver, o bine
directamente (suponiendo instalacin por defecto), tener una acceso directo previsto
al efecto con la siguiente direccin (verificar que el puerto que tenemos por defecto es
8080 para GeoServer):

http://localhost:8080/geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web
.importer.StoreChooserPage



En cualquier caso, sea el que sea el modo utilizado, cualquiera de las tres
formas nos conducen a la siguiente pantalla (caso de shapes):

Ah teclearemos las credenciales de administrador (si no se han cambiado en
preferences son admin y geoserver)

de manera que al entrar, Geoserver nos comunicar en la siguiente pantalla los
workspaces que ya tiene el servidor, no obstante, a nosotros nos va a interesar ahora


un nuevo workspace para gestionar este proyecto concreto al que llamaremos
COSLADA (No puede tener ms de 10 caracteres), tal y como vemos en la pantalla
siguiente:



Despus tenemos que meter el nombre (lo he llamado mmanso_coslada), una
descripcin y luego el directorio en dnde se encuentran los datos. En mi caso estn en
un directorio del disco D como se puede ver. Tras dar al botn Next, ya podremos ver
lo siguiente:

en el que nos aparecen el conjunto de capas disponibles (shapes). Podremos elegir las
que queramos para este workspace en concreto. En este caso se ha desactivado el
cruce y la masa porque no me interesan en este momento (podremos incluirlas
posteriormente en cualquier momento). Vemos que nos aparece el shape, as como un
smbolo que nos indica el tipo de datos que contiene tramos (polilnea), parcela
(polgono) y toponimia (punto). Al dar a importar datos, nos aparecer una pantalla de
porcentaje de importacin y finalmente el resumen de la carga:



Para saber que todo es correcto y que la proyeccin, datum y zona es correcta
podemos consultar en: http://www.epsg.org/ y descargarnos la EPSG dataset version
7.11 MS Access o la que haya en ese momento actualizada. En la tabla coordinate
Reference System de Access tenemos todos los EPSG disponibles, tal y como podemos
ver en la pantalla siguiente (BBDD Access que se descarga de la pgina segn lo
indicado)

Vemos que para el caso tratado, todo es correcto, se trata de proyeccin
ETRS89, geogrficas, Europa.


Volviendo a la ltima pantalla de importacin, vemos que podemos cambiar el
estilo de visualizacin y podemos ver la funcionalidad como WMS OpenLayers y su
interaccin con Google Maps. El uso de esto (simplemente pulsar), se puede ver en los
pantallazos siguientes:

O bien podemos realizar la llamada a la capa de informacin en modo WMS

O modificar el estilo de visualizacin con Styler:



Ahora vamos a realizar la misma tarea, pero atacando de forma directa a las
tablas de SDE. Esto requiere que Geoserver utilice el API SDE, lo cual habr que tener
en cuenta en la instalacin. Veamos esto sumamente importante antes de ver como se
incorporar la informacin a GeoServer.

Durante la instalacin deberemos de haber establecido la pestaa de
ampliaciones o extensiones. Al hacer esto, la instalacin de Geosuite nos saca una
pantalla advirtiendo de las operaciones que debemos de llevar a cabo.

Estos ficheros a los que se refiere el mensaje son en realidad los siguientes
suponiendo la versin 9.3 de ArcGis (jsde93_sdk.jar, jpe93_sdk.jar) que se debern
meter dentro del WEB-INF en el directorio lib. La versin 9.3 ya trabaja en caracteres
UNICODE, por lo que tendremos problemas para la conexin a SDE caso de no
incorporar en dicho directorio \WEB-INF\lib otra librera del API de SDE llamada
icu4j-4_2_1.jar. Si no hacemos esto al intentar conectar desde Geoserver con SDE nos


dar un error parecido a: Could not connect to the database, error is:
com/ibm/icu/text/UnicodeDecompressor. Aunque no parece necesario, el fichero
concurrent.jar, tambin es aconsejable, ya que para el manejo de SDE desde java es
necesario en muchos casos, aunque tericamente, como digo, Geoserver no lo precisa.

Simplemente por el hecho de haber metido los jar correspondientes al API de SDE, en
la pantalla correspondiente a la importacin de datos nos aparecer la posibilidad de
importar datos desde SDE, tal y como muestra la siguiente pantalla.

Como ya sabemos, SDE puede estar con gestor de soporte Oracle, SqlServer,
etc, no obstante no tenemos que tener en cuenta la direccin de dichos accesos a
BBDD, sino a la propia de SDE, la cual es siempre distinta. Los datos precisos para una
conexin a SDE son

- Server_adress o en Geoserver (HOST) :
- Instancia de conexin SDE o en Geoserver (PORT)
- Base de datos o en Geoserver (Instance Name)



Al pulsar el botn NEXT que hay en esta pantalla, nos aparecern todas las
tablas SDE. Se puede seleccionar en la parte de debajo de la pantalla que slo se
visualicen aquellas tablas SDE que tengan componente espacial.

Para un ejemplo, como el que se pretende, con seleccionar una capa es ms
que suficiente. Al aceptar aparece una barra en la que se puede ver el avance de la
importacin, de manera que terminado el trabajo, nos encontraremos en el mismo
caso del ejemplo de importacin shape.



Evidentemente de cara a la publicacin del WMS es muy interesante y
necesario el conocimiento del manejo de los SLD (adems Geoserver nos permite
hacerlo de forma muy sencilla). Pero este no es nuestro objeto y pasaremos
directamente a ver lo sencilla que resulta la publicacin del WMS una vez que tenemos
nuestras capas y las hemos aplicado los estilos deseados.

Lo primero que debemos hacer es ir a GeoExplorer:



Y aadir una capa usando el botn (+) Aadir layer:

Al entrar en la opcin de adicin vemos que podemos aadir datos desde
diversos servicios de mapas y de esta manera colocar por ejemplo una capa de algn
servidor externos de WMS (Comunidad de Madrid) o superponer capas de
openstreetmap a las de bing layers o cualquier otra de cara a conseguir el mapa
deseado.

En nuestro caso vamos a suponer que queremos aadir del servidor local (Local
GeoServer) las capas de construccin, portal y tramo del ejemplo de COSLADA que en
su momento importamos.


Al importarlas, las veremos sobre el mapamundi de fondo por defecto pulsando
sobre cualquier capa aadida el botn derecho del ratn y eligiendo la opcin (zoom to
layer extent).



momento en el cual podremos ver toda la extensin de la capa seleccionada sobre
dicho mapamundi al que en este caso GeoExplorer aade una capa de openstretmap
por defecto:

Ahora vamos a ver como importamos un nuevo servidor de WMS para aadir
capas deseadas a nuestro mapa:

Al ir a aadir una capa nos aparece la siguiente pantalla emergente que ya
hemos visto y en la cual podemos realizar esta operacin:



Al pulsar, por ejemplo podremos teclear el servidor de WMS de la CAM:

- http://www.madrid.org/cartografia/ide/wms/WMS_MAPAS_TOPOGRAFICOS.xml
- http://www.madrid.org/cartografia/ide/wms/WMS_ORTOIMAGENES.xml

momento en el cual aparecern todos los servicios disponibles y que son a fecha de
mayo de 2012 los que se muestran a continuacin en el primero de los casos, los
cuales podran tambin ser incorporados:

Ahora ya vamos a proceder a la publicacin de la cartografa, para ello
deberemos de saber la direccin del servicio a travs del cual GeoServer nos
proporcionar la informacin. Esto se determina del siguiente modo (botn Publish
Map):



Caso de aparecernos desactivada la opcin es porque no estamos logados en el
sistema. Debemos identificarnos como administradores (admin, geoserver, por
defecto) a travs del botn superior derecha y entonces veremos cmo podemos ya
pulsar la opcin Publish a MAP. Las opciones que nos aparecern despus sern las
siguientes:

Como vemos yo he pretendido desactivar algunas. Podemos aqu hacer una
previsualizacin si lo deseamos de cmo va a quedar nuestro servicio. La siguiente
opcin que nos sale es bsicamente de dimensionado que deber de aparecer:


Si copiamos el texto:

<iframe style="border: none;" height="500" width="500"
src="http://localhost:8080/geoexplorer/viewer/#maps/1"></iframe>

Y lo incorporamos a un html bsico, como por ejemplo:

<HTML>
<HEAD>
<TITLE>TFG Universidad de Salamanca</TITLE>
</HEAD>
<BODY>
<P>T.F.C. GRADo VILA (Geoexplorer)</P>
<iframe style="border: none;" height="500" width="500"
src="http://localhost:8080/geoexplorer/viewer/#maps/1">
</iframe>
</BODY>
</HTML>

El cual, guardaremos como XXXX.html, al ejecutarlo podremos visualizar algo parecido
a:



Habiendo procedido a la publicacin del mapa.

Se puede ver el conjunto de peticiones que se vienen haciendo a travs de la
consulta de los logs de C:\Users\Administrador\.opengeo\logs, que aparecen por da.
Del mismo modo, si hacemos una llamada directa a los servicios del servidor vemos
que Geoexplorer es uno de ellos:

As en la ruta de publicacin de servicios web de geoexplorer (C:\Program Files
(x86)\OpenGeo\OpenGeo Suite\webapps\geoexplorer\WEB-INF\app\root) tenemos
el javascript que se encarga de servirnos la imagen (viewer):


Y as, habremos publicado nuestro servicio con el GPL GeoServer.

Cualquiera de las opciones que decidamos usar es vlida, pero hemos visto que
en general ser necesario al menos, el conocimiento de una herramienta de
publicacin. Hemos intentado en este apartado dar los conocimientos tcnicos bsicos
para poder realizarlo sin problemas, tanto en el caso de que usemos una herramienta
propietaria como ArcGis Server, como una libre como Geoserver.



6
MANTENIMIENTO Y SINERGIAS

Va a analizarse en este captulo un rea que constituye algo fundamental, no
slo para un nomencltor, sino para cualquier aplicacin geomtica: el mantenimiento
de datos. Efectivamente es un tema descuidado en general, tal vez por obvio, tal vez
porque simplemente no se considera importante, pero el xito de un proyecto
depende bsicamente de l. El carcter divulgativo y de experiencia que pretendo dar
a este estudio no puede obviar este crucial desempeo de aquellos que nos dedicamos
o vamos a dedicar a la gestin de los nomencltores de grandes Organismos o
empresas. De nada sirve haber realizado el mejor y ms esmerado de los diseos, de
nada sirve que respondamos a todas las preguntas que del sistema se demande, de
nada sirve que tengamos servicios IDEE a disposicin y contemplemos las directivas
para una correcta interoperabilidad, si lo que respondemos es obsoleto o falso. Por
ello el mantenimiento y actualizacin de nuestro sistema es fundamental, permitiendo
la mejora de la informacin del nomencltor no normalizado que es una de las grandes
ventajas del sistema ya estudiado en captulos previos.

Por otro lado vamos a ver algunos ejemplos prcticos que nos ayuden a
comprender que un callejero no es un diseo y unas API, que tambin, sino algo
mucho ms complejo que implica un montn de aplicaciones propias tanto para su
mantenimiento como para su correcta difusin. As es: Uno de los grandes problemas a
los que fundamentalmente la Administracin se enfrenta es al conocimiento de las
utilidades desarrolladas. Parece mentira, pero es algo inherente a los grandes centros
no slo de la Administracin. La publicidad y difusin de un nomencltor es base para
su xito, los controles para su obligado cumplimiento por parte de aplicativos tambin,


para lo cual la direccin del centro de clculo o desarrollo informtico pertinente tiene
que tener muy claras las ventajas del mismo y nosotros ser unos buenos
comunicadores.

Las ideas, como las pulgas, saltan de un hombre a otro. Pero no pican a todo el
mundo.
(Stanislaw Lem)
La sinergia es estimulante. La creatividad es estimulante. Es extraordinario lo que
pueden producir la apertura y la comunicacin. Las posibilidades de que se produzca
una ganancia verdaderamente significativa, un progreso importante, son tan reales
que vale la pena correr el riesgo que esa apertura entraa.
(Stephen Covey)
Lo difcil es tener, si no sabes mantener.
(Annimo Refrn)



MANTENIMIENTO

CONCEPTO TIEMPO REAL V.S. BATCH

En el captulo cuatro, ya hablamos del procesamiento batch. Se trata ahora de
que comprendamos bien las diferencias entre el tiempo de proceso o real y el tiempo
diferido, procesamiento por lotes o batch.

Aquellas tareas en general que necesitan de la intervencin humana durante el
procesamiento, ya sean de monitoreo que puede suponer una decisin o de
interaccin continua con el sistema, se denominan de tiempo real o simplemente
interactivos, mientras que aquellas que son independientes de cualquier tipo de
interaccin humana en todo su flujo se denominan batch.

Como el tiempo real es bien conocido, vamos a detenernos a ver algunos
detalles del procesamiento batch que nos parecen no suficientemente conocidas. Un
proceso batch es un programa que interacta con datos realizando acciones en funcin
de un anlisis funcional realizado al efecto. La salida ser en general un alta, baja o
modificacin de datos normalmente de tablas o una salida de informacin con misin
especfica. Estos programas muchas veces dependen unos de otros, de manera que si
un determinado proceso no cumple ciertos requisitos, hace que otro batch se ejecute
o no, incluso puede suceder que en funcin de dicha salida se haya de ejecutar otro
batch diferente al que habra de lanzarse de haberlos cumplido. Todo este flujo de
operaciones los suelen realizar departamentos especializados en la gestin de
procesos, lo cuales en coordinacin slo inicialmente de los equipos de desarrollo
generan el flujo correcto, encargndose del procesamiento temporal de los mismos a
partir de las pruebas de xito iniciales. La ejecucin de cada uno de esos programa se
suele realizar a travs de JCL (Job Control Language), auxiliado por REXX (Restructured


extended executor) que es un lenguaje de programacin especfico para procesos
batch que permiten leer y escribir archivos, hacer manipulacin de cadenas, controlar
operaciones aritmticas, el flujo o la gestin de errores. REXX no es exclusivo, aunque
si genricamente utilizado en plataformas mainframe con Z/Os (editable

Ejemplo de un JCL de un ejemplo del manual de OPC de IBM Fte: IBM

mediante el editor de la herramienta de ISPF) u otros. Tambin puede ser usado en
otras plataformas como Windows, Linux etc (http://www.rexxinfo.org/ ). En algunas
plataformas windows, se sigue usando en vez de REXX, el procesamiento por lotes BAT


(en cualquier caso es con estos lenguajes con los que se ejecutan comandos como el
de envo de correos mediante BLAT a usuarios para conocer estadsticas de sus
procesos etc.) Adems junto a REXX se suele utilizar PRO JCL, que es un software de
validacin de conjunto.

Al mismo tiempo se utilizan en combinacin con las anteriores utilidades los
llamados planificadores, que en algunas tareas se pueden solapar con las anteriores,
pero que como hecho diferenciador tienen el que se encargan de modo muy eficiente
de coordinar lanzamientos entre procesos, horarios determinados y monitorizacin de
estados de los mismos.

Los ms conocidos son OPC, ahora llamado en su versin mejorada TWC (Tivoli
Workload Schedule) de IBM y M-CONTROL de BMC. Estos dos son con diferencia los
ms utilizados en el mundo. En grandes estructuras informticas resulta imprescindible
dado el volumen de procesos disponer de una herramienta de este tipo, sin las cuales
no slo sera mucho ms complicado establecer flujos concretos, sino que su
seguimiento, errores y otros sera imposible.

En cuanto al tiempo real, hoy en da en proyectos corporativos tendremos
fundamentalmente dos tecnologas, la tecnologa cliente-servidor y la tecnologa web.
Ambas no son excluyentes y tienen sus virtudes y sus defectos. Vamos primero a ver
que ambas tecnologas, en realidad son muy parecidas en concepto. Efectivamente por
un lado tendremos el servidor y por otra el cliente, cuando necesitamos descargarnos
un programa especfico para interactuar con el servidor estamos hablando del
denominado cliente pesado, mientras que cuando utilizamos una herramienta
universal para ello (navegador web) estaremos hablando de cliente ligero. En definitiva
en un cliente pesado (la actualmente llamada cliente-servidor de forma comn) el
computo de carga se equilibra mucho ms y el cliente realiza multitud de tareas dentro
del ordenador cliente, mientras que en un cliente ligero (la actualmente llamada
tecnologa web) prcticamente todas las operaciones se realizan en el servidor.



Pantallas de flujo y resultados de procesos del software de control BATCH de BMC

Sobre lo dicho cabran discusiones ms elevadas, pero para comprender el
concepto lo anteriormente dicho es perfectamente vlido. En una arquitectura de este
tipo lo normal es que tengamos tres elementos:


- Clientes que interactan con los usuarios finales.
- Servidores de aplicacin que procesan los datos para los clientes.
- Servidores de la base de datos que almacenan los datos para los servidores de
aplicacin.

En general usaremos tecnologa cliente-servidor cuando la cantidad de datos a
procesar es elevada y pesada y se requiera una interfaz muy personalizada de usuario,
mientras que cuando lo anterior no sea crtico utilizaremos tecnologas web.
Efectivamente podemos poner para ello un ejemplo claro: El de google earth. Google
es la empresa web por antonomasia, en general utiliza aplicaciones web (clientes
ligeros) en sus aplicaciones como gmail, por ejemplo, sin embargo a la hora de crear
una plataforma dinmica que le permita una interface rica de usuario y tarea aadida
en local utiliza plataformas cliente-servidor (cliente pesado) como es el caso de google
earth que precisa la descarga del software cliente que interacta con el servidor.

Vamos a mencionar la tecnologa P2P de pasada, ya que no suele ser utilizada
para usos geomticos, no obstante la ventaja principal de una red P2P frente a las
anteriores es que la cada del servidor no imposibilita el uso de la aplicacin, mientras
que en una red P2P los recursos estn distribuidos en varios nodos, de manera que no
todas las tareas quedan interrumpidas. Otra ventaja de una red P2P es que mientras
en los sistemas cliente-servidor (ya hemos visto que la tecnologa web es simplemente
un cliente ligero en un diseo cliente-servidor) puede llegar a existir un cuello de
botella en las peticiones a servidor frente a grandes demandas, en una red P2P el
ancho de banda aumenta con el nmero de usuarios pues se constituyen en nodos del
sistema. Por el contrario las plataformas cliente-servidor o web permiten una
centralizacin de recursos, una escalabilidad del sistema ms sencilla y un
mantenimiento simple sobre todo en lo que a hardware se refiere.

En cuanto a las plataformas las ms corrientes son la plataforma .NET(Visual
Studio) y la J2EE (WebSphere). Existe cierta tendencia hacia .NET por la multitud de
lenguajes que interoperan con l con curvas de aprendizaje inferiores y rendimientos
de calidad superiores (dato obtenido de TIOBE, que es una firma especializada en que
las empresas puedan medir la calidad del cdigo producido obteniendo una especie de


documento de eficiencia energtica, pero en este caso referida al cdigo). Documentos
como el de la empresa Middleware Company realizado por Herst, Edwars y Wilkes
vienen a sembrar de dudas lo que pareca un claro monopolio frente a la plataforma
Microsoft en costes y eficiencia. Adems surgen proyectos que hacen sencilla la
transicin a .NET partiendo de java, como el JLCA (http://www.microsoft.com/en-
us/download/details.aspx?id=14349) e incluso WebSphere parece haberse dado cuenta de
este hecho al garantizar la interoperabilidad java y .NET a travs de su plataforma por
medio de Websphere MQ.

Medicin de la calidad del software (status A: mximo) y lenguajes afectados - Fte: TIOBE

Veamos un estudio de demanda de programadores en lenguaje java y C# en el
Reino Unido que nos ayuda a ver la tendencia al equilibrio entre ambos lenguajes a
medio plazo:


Demanda de programadores java (arriba) y C# abajo en Reino Unido Fte: itjobswatch.co.uk

No quiero pasar por alto antes de continuar con los siguiente apartados, el
comentar un par de tcnicas especficas de programacin batch, que la experiencia me
dice que son poco estudiadas con lo que es fcil encontrarse programadores poco
expertos que las desconocen. El origen de ello es el aumento exponencial de sistemas
con alta capacidad que han hecho caer en el olvido tcnicas tpicamente COBOL de uso
comn antao, pero que hoy en da no han perdido vigencia en cuanto a optimizacin
de anlisis de procesos batch y que slo se vienen impartiendo en cursos
especializados de tcnicas de programacin. Fundamentalmente veremos uno
denominado enfrentamiento secuencial que es de gran trascendencia en el
procesamiento batch de cara a un rendimiento ptimo.

Imaginemos el caso de un fichero de PROVINCIAS a partir del cual queremos
obtener su cdigo de provincia por poner un ejemplo simple. Evidentemente podemos
recorrernos cada registro del fichero y hacer la seleccin correspondiente en la tabla


en la que tengamos guardadas nuestras provincias y su codificacin, de manera que
una vez encontrada escribamos en salida la entrada ms el cdigo encontrado. En el
grfico podemos ver las consecuencias de usar dicho mtodo viendo que los tiempos
ficticios se disparan a medida que aumenta el nmero de registros a tratar,
duplicndose de forma continua y exponencialmente con respecto al mtodo de
enfrentamiento secuencial.

Los tiempos se disparan si desconocemos las tcnicas de procesamiento batch

El problema es que estamos ante un caso sencillo en el que hay una sola
operacin que realizar y el caso podra ser an ms desfavorable, de manera que los
tiempos se podran triplicar y cuadruplicar, lo cual resulta inadmisible, mxime cuando
es habitual que los procesos batch se usen para tratamiento masivo de direcciones en
el nomencltor. Hay dos tcnicas a aplicar en estos casos, la ya comentada de
enfrentamiento secuencial y la divisin en hilos. Veamos cada una de ellas:

- Enfrentamiento secuencial: Este mtodo requiere de una clave. Dicha clave ser
el dato por el cual se realizar el enfrentamiento que podr ser entre dos
ficheros o un fichero y una tabla generalmente. Lo primero que hay que realizar
es una ordenacin del fichero y del dato de la tabla, de manera que podamos ir
realizando una comparacin registro a registro, con una sola lectura de la tabla
y una sola lectura del fichero. Ah la gran ventaja en tiempos. Veamos


esquemticamente como se realizara de cara a entender correctamente el
tratamiento tras la ordenacin y/o recuperacin de datos el enfrentamiento
entre un fichero y una tabla segn este mtodo.

Tratamiento esquemtico de enfrentamiento secuencial dato fichero campo tabla

- Divisin en hilos: Aunque la multitarea en sistemas Windows nace con el propio
Windows, en sus versiones primarias era cooperativa y por tanto arriesgada
para el uso de hilos. Es con el nacimiento de Windows NT y la aparicin de
multitarea preferente (mal llamada tambin apropiativa) cuando su uso es
seguro (tambin los son Linux y Unix) y sobre todo con el nacimiento de la
denominada multitarea real basada en mltiples procesadores sobre dichas
plataformas. Un sistema multitarea es capaz de dar servicio a varias tareas al
mismo tiempo bien mediante la distribucin de sus procesadores, bien
asignando tiempos de procesador a cada uno de ellos o una combinacin de
ambos, de manera que el tiempo de ejecucin real prcticamente no se ve
alterado, reduciendo los tiempos respecto a una ejecucin secuencial del
proceso. El uso de APIs de desarrollo hace que esta tcnica en algunos casos
sea conveniente respecto a la de enfrentamiento secuencial,


fundamentalmente ante complejos anlisis internos de datos resueltos en
cdigo por el API. El sistema se podra denominar divide et vinces como dijo
Julio Csar (en realidad este trmino suele usarse en informtica para resolver
problemas complejos por abstracciones de las situaciones sencillas que lo
componen). En este tipo de tratamiento el problema suele ser el tamao
ptimo de descomposicin, de manera que se suelen establecer en funcin de
la experiencia una serie de rangos de registros de entrada a los que se les
asigna una divisin dada. (En el ejemplo de programacin realizado en el
presente trabajo se realiza alguna operacin a travs de hilos)

La divisin por hilos (parte derecha) reduce el tiempo de ejecucin entre un 1/5 y 1/10 segn
experiencias propias respecto a tiempos originales de proceso secuencial (parte izquierda)



MANTENIMIENTO INTERNO

Pases y Municipios

Algo tan sencillo como en principio puede ser la lista internacional de pases no
lo es tanto. En principio tenemos dos lugares para consultar la lista de pases, una sera
el INE, otra el Ministerio de AAEE de Espaa y por ltimo la lista de pases de la ONU.
En la clasificacin del INE se tienen en cuenta criterios propios y especifican
claramente que pudiera haber ausencias (es una lista de pases para uso del censo,
movimientos migratorios, etc.), en la del Ministerio de Asuntos Exteriores aparecen
aquellas en las que Espaa tiene alguna representacin diplomtica y en la ONU
aparecen los estados miembros de dicha Organizacin. Cmo resolver este problema
de origen de fuentes?

- http://www.ine.es/daco/daco42/clasificaciones/paises_estandar.xls
- http://www.maec.es/es/MenuPpal/Paises/Paginas/listado-paises.aspx
- http://www.un.org/es/members/

Existen dos visiones para resolver el problema, en un primer momento del
estudio conjunto ver exactamente los pases distintos y en su caso establecer alguna
variante, o bien decidir la lista del INE para el caso de una gran AALL, ya que el enlace
padronal entre una corporacin municipal y el INE es importante al tenerle que
facilitar el primero al segundo los movimientos padronales. No obstante en otros casos
creemos recomendable establecer de entre estas tres fuentes los tem diferenciables
de manera que poseamos en nuestra BBDD de una lista ms completa de la que facilita
el INE, cuyos cdigos estn bastante estandarizados, dicho sea de paso, en todos los
intercambios de informacin entre Administraciones.

Me gustara resear que a fecha de hoy (1 de Enero de 2013), la lista del INE
tiene alguna ausencia como la de Sudn del Sur (independizada el 9 de Julio de 2011)
y presenta otros como Mayotte, que en realidad es un territorio francs (es como


poner las islas canarias como pas). Adems en la lista del INE podemos ver defectos
como el nombre Botswana, que en realidad es la forma anglosajona de nombrar a
Botsuana que si aparece correctamente escrita en los datos del Ministerio de AAEE.
Con todo esto quiero decir que la lista de INE es conveniente para un municipio por lo
antes reseado, pero es bueno completarla en la medida de lo posible. En el caso del
Ayuntamiento de Madrid, nos encontramos con el caso de ciudadanos que desean
empadronarse y al preguntarle lugar de nacimiento responden Regin Ecuatorial
Espaola (a partir de 1959 Guinea se constituy como una provincia espaola ms),
de manera que el personal municipal tiene verdaderos problemas, pues es una
realidad que esa persona es espaola y naci en una regin espaola, pero ahora ese
territorio se denomina Guinea Ecuatorial. La solucin es o tener una lista de provincias
histricas (con fecha de baja), o bien crear el pas Antiguas regiones espaolas (para
el caso concreto estudiado).

Es complicado realizar un tratamiento informatizado en este sentido y puesto
que no es frecuente la actualizacin (una revisin anual suele ser suficiente) lo
recomendable (ya que en nuestro caso si tenemos algunos pases propios en la BBDD
con codificaciones mayores de 900, para no solaparnos con las codificaciones INE), es
disponer de un proceso por enfrentamiento secuencial que nos proporcione las
diferencias con INE. El proceso consta de los siguientes pasos:

- Enfrentamiento secuencial codificacin INE
- Estudiar las altas por si estuviesen codificadas como propias. En ese caso
eliminacin de la codificacin propia y cambio de cdigo en el nomencltor no
normalizado.
- Estudiar posibilidad de bajas. Si hay datos no normalizados se apunta para no
ser utilizada nuevamente, pero no se elimina, pues dispone de datos asociados
del nomencltor.
- Estudiar las modificaciones. Si se trata de cambio oficial de nombre actualizar,
caso contrario estudiar si se trata de un alta-baja (aplicar en cuanto a no
normalizados los casos alta y baja)
- Modificacin de nombres exnimos ajenos al exnimo espaol y generacin de
variante de pas con el exnimo ajeno.
- Revisin de listas de la ONU y del Ministerio de Asuntos Exteriores. Alta propia
en su caso.


Como vemos se trata de una tarea muy manual, pero a da de hoy no tenemos
una garanta absoluta de cmo se trata esa informacin, de manera que se requiere el
estudio antes comentado. Se trata de un dato que muchas Administraciones
raramente actualizan, pero que creemos necesario realizarlo anualmente.

Las provincias espaolas no varan prcticamente salvo por condicionantes
lingsticos. En ese caso se debe de proceder a su modificacin siempre en su forma
oficial. Como variante es conveniente dar el alta todas aquellas formas toponmicas
por las que sea conocida la provincia. El INE en realidad se basa tambin en la
informacin del registro de entidades locales del Ministerio de Hacienda y
Administraciones Pblicas en el suministro de esta informacin, ya que sabemos que
este es el nico registro oficial para este tipo de datos y adems codifica las provincias,
de manera que esta codificacin nos ser til a la hora de actualizar los municipios. Por
comodidad y salvo alguna noticia lo ms cmodo es dar un repaso a los mismos y
modificar en su caso difundiendo dicha informacin por todas las tablas afectadas.
Diremos que la Comunidad Autnoma como divisin administrativa en una
Administracin Local no tiene ninguna trascendencia, por lo que puede o no ser
contemplada (El Ayuntamiento de Madrid no lo hace). La direccin de las fuentes es
para las provincias:

- http://www.ine.es/daco/daco42/codmun/cod_provincia_estandar.htm
- http://ssweb.mpt.es/REL/frontend/inicio/provincias/all

Por su parte los municipios (en la actualidad 8.118) si tienen un nico
proveedor de informacin y este es el ya mencionado registro de entidades locales,
sin embargo y dada la necesidad del censo de mantener esta informacin actualizada
resulta mucho ms cmodo recuperarla del Instituto Nacional de Estadstica:

- http://ssweb.mpt.es/REL/frontend/inicio/index
- http://www.ine.es/daco/daco42/codmun/codmun/12codmun.xls



Es importante tener en cuenta la codificacin de provincias a la hora de
actualizar los municipios. El sistema debe basarse en un enfrentamiento secuencial
entre los datos de municipio disponibles y los datos actuales de nuestra tabla del
nomencltor. La estabilidad de la codificacin viene garantizada por el INE, por lo que
se puede realizar de modo automtico, sin mayor complicacin.

Hemos visto que la actualizacin de pases y provincias requera una cierta
intervencin humana, mientras que la tabla de municipios ya no. A partir de aqu, dado
entre otros el volumen de informacin todos los procesos sern automticos. Veamos
un pequeo extracto de cdigo java del enfrentamiento secuencial para actualizar los
datos de municipio del nomencltor.
..
BufferedReader fINE = new BufferedReader(new FileReader(FILE_ENTRADA_MUNICIPIO_ORDENADO));
BufferedReader fBDC = new BufferedReader(new FileReader(fichBDC2Ordenado));

System.out.println ("Al empezar el enfrentamiento municipio es BDC-INE: "+(new
Timestamp(System.currentTimeMillis())).toString());

cadenaINE = fINE.readLine();
cadenaBDC = fBDC.readLine();

while ((cadenaINE != null) && (cadenaBDC != null)) {

registroINE = cadenaINE.substring(0,45);
registroINE = registroINE.toUpperCase().trim();
cod_municipio_INE = cadenaINE.substring(0,5);
lit_municipio_INE = cadenaINE.substring(5,40);
registroBDC = cadenaBDC.substring(0,45);
registroBDC = registroBDC.toUpperCase().trim();
cod_municipio_BDC = cadenaBDC.substring(0,5);
lit_municipio_BDC = cadenaBDC.substring(5,40);

System.out.println(registroINE+" - "+registroBDC);


if (cod_municipio_INE.compareTo(cod_municipio_BDC) < 0) {
// < 0 INE es menor que BDC
// = 0 INE es igual que BDC
// > 0 INE es mayor que BDC

// Estos registros sern para insert.
System.out.println("Insert de : "+registroINE);
cadenaSalida = registroINE;
fichNE_BDC.println(cadenaSalida);
escritos_noenc_BDC++;
.. etc.

Poblaciones

El caso de las poblaciones es un caso aparte. An cuando el INE nos puede
facilitar esa informacin (de hecho se actualiza en el caso de Madrid slo para ncleos
de poblacin) no tiene mucha relevancia y se usa ms a efectos de facilitar el camino
hacia la poblacin que realmente nos interesa (A), pues la informacin suministrada
por el INE no garantiza un adecuado envo postal. Es por ello por lo que en el caso de
una Administracin Local, an disponiendo de dicha informacin, la que resulta
realmente prctica es la que nos puede suministrar el Organismo Autnomo de
Correos. La informacin de Correos al respecto es bajo contrato y tiene un pequeo
coste aproximado de entre 700 y 1000 euros anuales.

- https://www.correos.es/comun/marketingdirecto/01-IdentificarCliente/06-BDCodigoP/06-
MDBDCodigoP/12010606d-BDComoobtener.asp

En el caso del nomencltor del Ayuntamiento de Madrid, las poblaciones estn
divididas en cuatro tipos (calificador de la poblacin) de manera que tenemos:



1. Tipo I: Cuando la poblacin pertenece al INE
2. Tipo P: Cuando la poblacin pertenece a Correos
3. Tipo X: Cuando la poblacin pertenece a INE y a Correos
4. Tipo A: Cuando la poblacin pertenece al Alfoz de la CAM
5. Tipo C: Otra poblacin pertenece a la Comunidad de Madrid

Las poblaciones de la Comunidad de Madrid, es decir aquellas que afectan al
nomencltor propio y al nomencltor metropolitano no se actualizan de este modo (si
en el caso del INE, no en el caso de Correos), ya que su actualizacin se realiza de
acuerdo a los datos de la propia Comunidad. Por tanto slo se actualizan las
poblaciones del nomencltor estatal. Los tipos I se suelen actualizar cada ao al tiempo
que el resto de los datos INE (un dato tipo I puede desaparecer, puede aparecer un
nuevo tipo I o bien un tipo A puede pasar a ser P o un P existente pasar a ser A), sin
embargo los datos realmente trascendentes son para una AALL los relativos a Correos,
los cuales se actualizan de forma trimestral. Dicha actualizacin se realiza por
comparacin del cdigo provincial y el nombre de pueblo por lo que aquellos pueblos
que desaparecen pasan a formar parte de una tabla especial de variantes de pueblos
gestionada en tiempo real por la estafeta postal municipal y en el que a un cdigo de
provincia ms un literal desaparecido se le podr asignar un cdigo de pueblo actual.

El proceso incluye la ligazn, siempre que es posible con el municipio de INE y
la actualizacin de datos del nomencltor no normalizado. Adems el proceso se
vincula con la actualizacin de los callejeros del nomencltor estatal, caso de terminar
correctamente el proceso.



Pantalla de tratamiento de variantes de poblacin gestionadas por la estafeta postal

Activacin de procesos batch para la normalizacin de pueblos en el nomencltor no normalizado



Vamos a comentar aqu un detalle importante del tratamiento en tiempo real
de las decisiones tomadas para el caso de la Comunidad de Madrid:

Toda la informacin disponible de calles de poblaciones de Madrid se
encuentra en los registros que provienen de la Comunidad, es decir aquellos cuyo tipo
de pueblo es A C, de manera que deberemos tender hacia ellos, sin embargo y para
mejorar la bsqueda se incluyen en la SELECT todos los registros cuyo CODMUN sea no
nulo, asegurndonos de esta manera que tendremos un cdigo de municipio A C que
nos permitir buscar la calle tambin. As, una vez seleccionada por el usuario la
poblacin correspondiente nosotros realizamos una segunda bsqueda por ese mismo
cdigo de municipio y que adems tenga como tipo de pueblo las codificaciones A C.

Determinacin de pueblos A/C para el cdigo de municipio 58 de Madrid.



Supongamos que en una bsqueda de la provincia de Madrid alguien ha
tecleado LOS BORRACHITOS, como poblacin, de manera que encontraremos una
poblacin vlida en la BBDD como correspondencia al registro existente
BORRACHITOS (LOS), que el usuario seleccionar (tipo I de INE) y nosotros
cambiaremos por FUENLABRADA (tipo A de la Comunidad), ya que es ah en donde
tenemos todo el callejero de dicha poblacin incluidas todas las posibles calles que
haya en los Borrachitos, con lo cual habremos optimizado la gestin. Adems los
cdigos postales estn actualizados para esa poblacin (Fuenlabrada), que es en donde
tiene sentido hacerlo, con lo que mejoramos sustancialmente las caractersticas de
bsquedas para una poblacin.

Callejero municipal

En realidad en esta opcin hablamos de callejero municipal como sinnimo de
nomencltor propio o intrnseco. Tngase en cuenta que el callejero municipal incluye
calles, nombres populares y topnimos de la ciudad, de modo que con toda propiedad
estamos gestionando el nomencltor de forma completa.

El Departamento de Cartografa del rea de Gobierno de Urbanismo y Vivienda
es el encargado de realizar el mantenimiento tanto cartogrfico como alfanumrico
del nomencltor propio de la ciudad. Para ello dispone de una serie de aplicaciones
que se manejan continuamente y llegado un punto, un proceso identifica los
elementos consolidados de dicho tratamiento y los transfiere a travs de red, usando
la tecnologa linkedserver entre BBDD. Tras ello un proceso batch se encarga de la
actualizacin efectiva en el conjunto de BDC disponible para ponerlo a disposicin de
los aplicativos municipales. Este proceso es diario. Para los datos espaciales existe un
nodo (repositorio) SIGMA (Sistema de Informacin Geogrfica Madrid) en el cual se
incorpora la capa a modificar, de manera que hasta el momento, de manera manual se
actualiza, primero en desarrollo y tras el visto bueno, en entorno de real.



Esquema bsico de interaccin y flujo de la actualizacin del nomencltor intrnseco



Pantalla de monitorizacin de estado de procesos de actualizacin diaria con Urbanismo en los distintos
entornos gestionados en BDC - Informtica Ayuntamiento de Madrid (nomencltor propio).

Todo el proceso es revisado al da siguiente, puesto que los procesos batch
envan un correo de estados y movimientos realizados en el nomencltor propio e
incluso se dispone de una aplicacin en la que se valida que todos los entornos han
sido actualizados y en la que se puede detener manualmente el envo de movimientos
del da siguiente (la prohibicin de nuevos envos es automtica caso de que se haya
producido algn tipo de error en la consolidacin de datos en algn entorno). El que se
produzca algn error es consecuencia normalmente de la diferencia en los diseos de
tablas (fundamentalmente algn ndice nico) que es resuelta por el personal de BDC
(nomencltor municipal), desbloqueando la situacin, momento en el cual y de forma
manual se abre el semforo de movimientos para que el Departamento de Urbanismo
pueda enviar los del da siguiente. Los procesos automticos leen estos semforos en
todo momento. As mismo existe un semforo interno en la parte de BDC que impide
cualquier tipo de ejecucin de procesos batch que afecten al nomencltor propio
durante la consolidacin de informacin. Lgicamente y como debe de ser una norma
en todo proceso batch la actualizacin de informacin no se consolida hasta que el


ltimo movimiento se ha producido, momento en el cual se realiza el commit o end-
transaction (dependiendo del lenguaje) o en su caso el rollback o backout transaction
para devolver el estado de la BBDD al momento previo al inicio del proceso. Esto,
aunque obvio, es importante de sealar: Las transacciones se tratan siempre en bloque
completo, pues de lo contrario es harto complicado regresar a una situacin
suficientemente estable y conocida de la BBDD del nomencltor. An as, se guarda un
log acumulado de todos los movimientos realizados en la actualizacin del
nomencltor intrnseco, de manera que podra seguirse la pista de algn problema si
este se presentase anacrnicamente.

Dado que se podra llegar a crear una situacin (durante el periodo de vida de
BDC esta situacin se ha dado una nica vez y adems no ha sido producida en este
escenario) de error en datos, en BDC se dispone de un semforo de procesos de
tiempo real que impedira en un momento dado del uso del nomencltor en procesos
de tiempo real mientras se subsana la incidencia. Esta situacin es sumamente grave,
pues imposibilita el funcionamiento de la mayora de las aplicaciones municipales y
slo se debera de dar si no es posible la resolucin en caliente del problema.



estadoCMDHOST.jar
Cambio
de entorno
HOST
CMDNPNT2
(comprueba parmetro :
CARGACMDHOST)
Retorno
es 0
(RC=10)
Email con fichero de error
RC=23 (general) o RC=25
(error en movimientos HOST)
NO
UNLOADMOVDIARIOS.jar
Semforo
abierto?
(CONTROL_
GMU = S
Semforo cerrado por
Urbanismo. Se nos impide el
acceso.
NO (RC=25)
FIN PROCESO
GENERACIN DE
FICHEROS CON
MOVIMIENTOS PARA
HOST
Hubo un problema en la
generacin de ficheros
Email con NO HAY
MOVIMIENTOS A DA DE
HOY.
RC=25
RC=77
RC=10
MOV TXT PARA
HOST
CargaCMD.exe
(Visual)
RC=10
Cambio
de entorno
HOST
CMDP400
(Copia a MOV EN
HOST)
Error?
SI (RC=25)
ActParamHOST
Con parmetro 1
PONE CARGACMDNT a 1
ActParamHOST
Con parmetro 1
PONE CARGACMDNT a 0
Y CARGACMDTRANS a 1
Correo de errores
NO (RC=10)
CUMPLE CONDICIN

Flujo bsico del sistema de movimientos diarios desde Urbanismo a BDC



Otros callejeros

Como ya hemos visto el mantenimiento del nomencltor metropolitano se
realiza a travs del envo de cierre de callejeros de la Comunidad de Madrid quien nos
provee de dicha informacin y del Organismo Autnomo Correos en el caso del
nomencltor estatal.

En el caso del nomencltor estatal, la actualizacin se realiza seguidamente de
la actualizacin trimestral de poblaciones desde la informacin suministrada por
Correos. Se trata en nuestro caso de una informacin enfocada a la entrada de
direcciones no normalizadas de alta calidad en un momento dado, pero no
mantenemos historia alguna de este nomencltor, por lo que es utilizado en modo
consulta de cara a obtener direcciones correctas. Se trata pues de un nomencltor
voltil y que trimestralmente vara, por lo que las codificaciones en cuanto a calles son
absolutamente ficticias y no pasan a formar parte del registro grabado en el
nomencltor no normalizado. En definitiva el nomencltor no normalizado contendr
TODAS las direcciones que el sistema precise para fuera de la Comunidad de Madrid
an cuando dichas direcciones sean perfectamente vlidas y ese es el fin perseguido
con el nomencltor estatal. Las tablas usadas en dicho nomencltor son:

- VIAL_NACION: Contiene los viales por poblaciones
- VIAL_NACION_POSTAL: Tramero postal de las calles de VIAL_NACION
- VIAL_NACION_FONOS: Fonos derivados de las calles de VIAL_NACION
- VIAL_NACION_PVACIAS: Contiene las palabras que sern eliminadas de
bsquedas.
- VIAL_NACION_CLASE_TRADUCTOR: Contiene los tipos de va en otros idiomas
oficiales de Espaa en sus respectivas Comunidades Autnomas.

El sistema que se utiliza para regeneracin de tablas en el nomencltor estatal
es el mismo que se aplica de cara a su bsqueda, es decir, se eliminan palabras vacas,
se busca por coincidencia y fonos-grafos y sino, por semejanzas. Por otro lado para el
caso del nomencltor metropolitano se tienen las siguientes tablas:



- CLASE_CAM: Contiene las clases vlidad en la Comunidad de Madrid
- VIAL_CAM: Contiene los viales por pueblo
- APP_CAM: Contiene las numeraciones de cada vial

a las que se aade la correspondiente a la tabla, denominada plana en donde toda
direccin aunque pase a ser baja queda contemplada por una combinacin
clase+cdigo irrepetible, pero que no se puede volver a recuperar. As mismo el
sistema se establece por codificacin segn la CAM, por lo que se da un sistema mixto
a nivel de historia entre el nomencltor propio (historia completa) y el nomencltor
estatal (sin historia), de acuerdo a las necesidades reales del municipio.

http://www.correos.es/comun/marketingDirecto/01-IdentificarCliente/06-BDCodigoP/06-
MDBDCodigoP/Estructura_BD_Codigos_Postales.pdf

Descripcin del formato de ficheros suministrados por Correos

MANTENIMIENTO ASOCIADO

La codificacin postal

Ya hemos visto la asociacin entre la carga del nomencltor estatal y su
inseparable asociacin con la carga de la codificacin postal, por lo que sobre ella no
incidiremos ms.

Respecto a las cargas de datos postales en el nomencltor propio y
metropolitano, la forma de proceder es idntica, ya que la informacin que se precisa
es del mismo nivel (distrito postal y seccin de cartera asociadas a una direccin) de
manera que podemos distinguir entre el mantenimiento continuo y el mantenimiento
peridico. El mantenimiento continuo se hace a travs de la estafeta postal municipal,


que se enmarca en el Departamento de digitalizacin, microfilmacin y estafeta postal
y que est en permanente contacto con usuarios y el Organismo de Correos. Las
modificaciones se realizan por demanda de un usuario previa contrastacin o por
demanda puntual de Correos. Para ello el nomencltor les ha dotado de una aplicacin
desarrollada al efecto, de manera que dicha informacin se modifica directamente en
el propio nomencltor.

Slo los usuarios autorizados de la aplicacin y el propio personal de BDC
pueden interactuar con la aplicacin. Su uso se basa en un sistema de trameros por
poblacin y calle al que se puede acceder mediante cdigo de vial o bien a travs de la
literatura de la va y as mediante sesin se realiza la operacin de prohibicin de
entrada a una calle que est siendo editada por otro operador, quedando una calle
bloqueada para gestin si otro usuario ya la est gestionando. Debemos decir que si la
arquitectura dispone de un balanceador de carga entre varios servidores, el sistema de
sesin no funciona, ya que una sesin se establece a nivel de servidor y en el sistema
detallado el balanceo no nos garantiza el servidor al que iremos por lo que la solucin
pasa por algn diseo de BBDD. Se trata de una solucin no tan eficiente como la de la
sesin, pero que nos indica de nuevo la interrelacin del conjunto y la importancia de
todo lo visto en captulos anteriores. El balanceo de carga es una tecnologa de
arquitectura de ordenadores basada en regular el trfico entre servidores, de manera
que se asignan tareas a los ms liberados. Lgicamente todas las parametrizaciones de
datasource respondern a una nica BBDD.

Por otro lado y bajo demanda bien de Correos, bien de BDC se procede a una
actualizacin completa de callejeros. Hemos de decir que dicho Organismo Autnomo
recibe semanalmente los datos de altas, baja, modificacin del callejero para Madrid,
de manera que existe un flujo continuo de informacin entre el Ayuntamiento y
Correos. Cuando uno de los dos centros ve la necesidad, bien por el tiempo
transcurrido, bien porque se detectan porcentajes no admisibles de errores en el
reparto, se procede a una revisin completa, para lo cual Correos nos enva unos
ficheros normalizados en un tramero con codificacin propia que se procesa
automticamente.



Ejemplo de pantalla de la aplicacin para el mantenimiento de informacin postal

La informacin estadstica

Entendemos por informacin estadstica asociada al nomencltor a aquella
derivada del Departamento de datos Estadsticos de la Direccin General de Estadstica
del Ayuntamiento de Madrid y que bsicamente se refiere a la informacin de
distritos, barrios y seccionado censal. La correspondiente a distritos y barrios, en
realidad no es informacin que dependa de ellos directamente, no obstante al estar
dicha informacin tan ligada a la del seccionado desde BDC preferimos que sea
coordinada por ellos y as los bloques de divisin abstractos de la ciudad se muevan en
un conjunto homogneo hasta el nomencltor, lo cual simplifica adems la gestin.



La manera y tiempos en que se procede a esta actualizacin es responsabilidad
completa del mencionado Departamento de datos estadsticos, a la cual BDC ha
proporcionado las herramientas suficientes para poder gestionar dicha informacin
autnomamente. El seccionado censal permite la divisin ponderada de habitantes en
torno a un mbito geogrfico unificado. Para el correcto estudio de dicha informacin
se precisa tanto la informacin padronal, como la informacin de BDC que
previamente haya sido cargada (siendo la utilizada en todo el Ayuntamiento) de la
correspondencia entre los portales y dicho seccionado. As mediante una aplicacin
SIG sobre un nodo SIGMA al efecto, personal cualificado se encarga de realizar dicha
tarea de gestin. Un esquema a vista de pjaro del proceso sera el siguiente:

Como vemos el Departamento de datos estadsticos interacta en peticiones al
nomencltor y en su propio trabajo, de manera que los procesos entre nomencltor
BDC y nodo BDC-SIGMA bien para carga del nodo, bien para recoger datos de l como
medio de consolidacin de datos estadsticos en BDC es totalmente automtica y
basada en procesos batch nocturnos, de los cuales se reciben correos electrnicos de
estado y estadsticas por si surgiera algn revs.


Aplicacin del nomencltor para la gestin de la informacin estadstica del nomencltor propio.

Como vemos en la pantalla arriba indicada, a travs de esta aplicacin del
nomencltor el personal del Departamento estadstico es capaz de gestionar todo el
proceso contra el nomencltor sin intervencin del personal de BDC (importantsimo
dada la escasez de medios personales de los que disponemos), de manera que hay
varias posibilidades entre las cuales se encuentra la de simulacin (sin actualizacin) u
otras derivadas de necesidades de carga. Todos los cambios que se realicen en el
seccionado recibirn un hito en su historia, de manera que seremos capaces en todo
momento de simular la historia estadstica de un determinado portal. Esto permite que
el Departamento de Estadstica y el de Padrn reciban notificaciones de dichas
modificaciones que llegan mensualmente o a peticin:



Peticin de notificaciones de fichero/listado de variaciones estadsticas mensuales y/o a peticin.

Por ltimo comentar dos cosas. Primero, que el seccionado slo afecta a los
datos del nomencltor propio a los del nomencltor no normalizado para aquellas
aplicaciones que demanden dicha necesidad de forma continua (Aplicacin del Padrn
Municipal de Habitantes) y segundo que en la actualizacin realizada se procede, si es
el caso a la georreferenciacin de datos no normalizados de Padrn.

Por otra parte el mencionado Departamento se encarga en su caso de corregir
problemas puntuales en el seccionado de otras aplicaciones distintas a Padrn que
tengan no normalizados a tratar, de manera que disponen de una aplicacin ex
profeso para ello, tal y como se puede apreciar en la pantalla siguiente.



Pantalla en la que se puede apreciar la modificacin de datos censales en el nomencltor N.N.

Los ndices fiscales

El tratamiento de ndices fiscales va asociado histricamente en el municipio de
Madrid a los portales ya que numerosos impuestos se basan en ellos como elemento
correctivo de la tasa en cuestin. Por ser un elemento pues, vinculado directamente al
nomencltor es por lo que tras su aprobacin en Pleno debe de estar disponible como
parte de los datos del propio nomencltor.

El Organismo competente en la elaboracin de dicho ndice es la ATM (Agencia
Tributaria de Madrid) para quien BDC tiene que establecer los mecanismos adecuados
para una correcta interoperabilidad con la realidad de la ciudad. Dicho proceso se
realiza al igual que en el caso de datos estadsticos sobre una plataforma SIG (nodo de
SIGMA), de manera que el mecanismo es similar a aquel. En este caso la realidad es


preciso tramificarla de acuerdo a como se vienen trabajando dichos ndices. As pues
aunque el anlisis es superficial, BDC debe segmentarlo por tramos de calle y
numeracin proporcionando el listado que se aprobar en Pleno.

http://www.madrid.es/UnidadWeb/UGBBDD/ObjetosExternos/Ficheros/Indice%20de%20Calles%202011.pdf

Aplicacin BDC de gestin de ndices fiscales del Ayuntamiento de Madrid para ATM

Al mismo tiempo y dado que antes de su aprobacin puede ser necesario el
tratamiento de alguno de dichos tramos, BDC pone a disposicin de la ATM otra
aplicacin que le ayuda a terminar de pulir los datos con respecto a la realidad del
nomencltor, bien porque en el periodo desaparecen calles, se les cambia de nombre
o aparece alguna nueva que hay que tener en cuenta. Para ello y ya sobre los datos
previos validados y estudiados de forma espacial se puede proceder a modificaciones
puntuales (antes de su aprobacin definitiva). Desde dicha transaccin adems se


realiza la distribucin real por el nomencltor propio y el no normalizado que son a los
que afectan los datos de ndice fiscal.

Tratamiento de depurado de ndices fiscales, listados de Pleno y anlisis para ATM

Me gustara destacar un aspecto importante. Cabe preguntarse que si el
anlisis en este caso se realiza en un primer estadio mediante estudio por polgonos
basados en criterios de valoracin catastral de parcelas y algunos otros sera lgico el
realizar la consolidacin en el nomencltor por un anlisis de tipo espacial, no obstante
no podemos obviar el carcter real del nomencltor no normalizado, de manera que
la operativa a realizar sobre aquellas inscripciones tributarias ligadas a una direccin
no normalizada en el nomencltor no tendran solucin posible, pues en principio
carecen de coordenadas. La tramificacin resuelve un altsimo porcentaje de casos y
ayuda a ver una coherencia en la informacin de una calle. En el nomencltor no
normalizado se permite la asociacin de coordenadas y la georreferenciacin, pero el
realizar esta tarea no puede estar vinculado a los operadores de gestin de las


aplicaciones, por lo que caso de querer proceder a una zonificacin de valor por
mbito superficial (como en nuevos impuestos se est estudiando) se debe de tener
muy en cuenta este extremo y valorarlo en la forma adecuada que ser la de
simulacin como ms efectiva.

El servicio de estacionamiento regulado (S.E.R.)

El servicio de estacionamiento regulado, ms conocido por S.E.R. depende a
efectos del nomencltor del Departamento Administrativo de Estacionamiento
Regulado perteneciente a la Direccin General de Sostenibilidad del Ayuntamiento de
Madrid, de manera que la administracin de dichas zonas se realiza directamente
sobre una aplicacin desarrollada por BDC para dicho gestor de informacin apoyada
en el mismo.

Aplicacin de gestin del S.E.R. municipal manejada por el Departamento de Estacionamiento Regulado.



En este caso, como vemos la gestin se basa en un uso directo de acciones
sobre el nomencltor, sobre el cual se puede trabajar aisladamente consolidando
dichas acciones en el momento en que ello corresponda. A parte de dicha gestin y
una vez consolidada la informacin como definitiva, BDC pone a disposicin de dicho
servicio el poder obtener listados y/o ficheros bien para gestin directa de oficinas,
bien para ser proporcionada a las empresas concesionarias del servicio en cada zona
(formatos concesionarios) para posteriormente ser cargada. Adems en esta misma
pantalla se incluyen posibles salidas para uso (restringido a zonas SER o para todo
Madrid) de dispositivos mviles dotados con GPS, como pueden ser coches de
urgencia o servicios municipales de inspeccin.

Otros mantenimientos

Un nomencltor de una gran AALL necesita de un continuo mantenimiento. En
otros momentos la aplicacin BDC municipal tuvo un personal municipal ms elevado,
no obstante en la actualidad el sistema debe de ser mantenido por 1/4 del que en su
da tuvo, por lo que resulta complicado realizarlo de forma minuciosa. Este hecho ha


venido siendo progresivo por lo que hemos tenido que saber adaptarnos a la situacin
procurando minimizar su efecto por la automatizacin completa de aquellas tareas
susceptibles de poder hacerse, de manera que el estudio de nuevas mejoras en el
momento actual basada en estudios internos est prcticamente paralizada.

Creo interesante comentar esta realidad, pues el 100% del desarrollo
alfanumrico y de anlisis espacial de BDC se lleva a cabo por personal municipal sin
que empresas externas hayan participado en ello (salvo en el caso de soportes de
programacin puntuales ante una carga extra de trabajo), lo cual minimiza el coste real
del nomencltor del Ayuntamiento de Madrid (que es lo que tiene que hacer cualquier
Organismo Administrativo: optimizar el dinero de los ciudadanos).

Vamos a poner ejemplos de algunas tareas de mantenimiento comunes que se
realizan. Insistimos que un chequeo continuo de la informacin mediante la BBDD,
comportamientos no esperados, mejoras en procesos etc. es continuo:

- Data Warehouse: Un data warehouse es un repositorio o almacn de
informacin de diversas fuentes cuyo fin es su transformacin para obtener
informacin til, para lo cual estn dotados de sistemas de soporte de
decisiones (DSS) y soporte de informacin ejecutiva (EIS). El nomencltor
provee de dicha informacin mensualmente ha dicho sistema.
- Cdigo de vial de INE: El Ayuntamiento de Madrid dispone de su propio cdigo
de vial, no obstante con el fin de lograr una mxima interoperabilidad con el
resto de Administraciones mantiene a travs de la ATM dicha equivalencia.
- BBDD externas: El nomencltor municipal se reparte entre otros Organismos.
As mismo muchas aplicaciones necesitan conocer a diario si se han producido
determinada casustica sobre la ciudad, de manera que BDC se encarga
diariamente de indicarles a travs de tablas propiedad del aplicativo
demandante de la informacin (nica forma de automatizar la tarea) si dichos
casos se han producido. Ejemplos de estos ltimos son la Inspeccin Tcnica de
vehculos, Responsables de Pavimentos, Servicios Sociales y Servicios de
Inspeccin entre otros.
- Preparacin de listados: La carga en tiempo real que supondra la realizacin de
determinados listados obliga a BDC a realizar a una fecha dada informes


especficos (semanalmente se renuevan) capaces de dar el soporte necesario
en cuanto a listados o ficheros resueltos en tiempo real, fundamentalmente en
lo que respecta a direcciones y codificacin postal. Evidentemente ante
cualquier urgencia se pueden ejecutar en el da, pero la experiencia nos dice
que ello no es habitual.

Aplicaciones de la intranet municipal que hace uso de los procesos de obtencin de listados
(vase la fecha indicando la actualizacin de la informacin)


- No normalizados: Los registros no normalizados tienen procesos especficos
como los de normalizacin de viales y numeraciones, consolidacin de
variantes o actualizacin de literales por cambio de nombre. Con ellos tambin
interaccionan variantes y aplicaciones para su carga y estudio con el fin de
mejorar continuamente la informacin.
- Tablones: Diariamente se mantienen los denominados tablones. Son tablas en
las que se almacena toda la historia de cada direccin desde su nacimiento
hasta la actualidad. Se ponen a disposicin de quien necesita usar este tipo de
informacin para estudios muy concretos.
- Algunos puntos de inters (POI): Cuando el CTM de la Comunidad de Madrid
nos enva modificacin de datos de transportes la actualizacin se lleva a cabo
a travs de una BBDD Access y un determinado esquema. Se cargan lneas y
paradas del conjunto de los transportes de la ciudad, excepto el
correspondiente ak de paradas de taxis que se gestiona internamente.

Ejemplo de uso en consultas de datos de CTM proporcionados en Access.


Adems se hace uso de la aplicacin de Gestor Municipal de Contenidos que
opera bajo la plataforma Vignette (Dentro de gestores de contenidos y pginas
web tambin tenemos Filenet de IBM o EMC), de manera que slo se recoge
aquella informacin que resulta til de cara a la plataforma del nomencltor a
travs de un Web Service.

Ejemplo de uso en consultas de datos del Gestor de Contenidos Municipal.

Por ltimo, existe una aplicacin (ver figura de abajo) que permite
modificar y cambiar la georreferenciacin de datos, aadir nuevos etc. Tngase
en cuenta que se trata de un repositorio de POI de diversos orgenes y que la
edicin sobre los mismos se hace necesario en el contexto de BDC. Eso s, existe
una tabla de autorizaciones de manera que cada usuario puede actuar sobre
cierto tipo de datos.



Aplicacin de gestin de los puntos de inters del nomencltor propio o intrnseco.

- Enrutamientos postales: Toda la gestin se realiza por parte de la Estafeta
Postal en una aplicacin realizada por BDC. Adems para aquellos procesos que
lo necesitan existe un pequeo batch o API a disposicin que permite la
extraccin de dicha informacin (para uso en memoria, dado su pequeo
tamao, de cara a optimizar tareas y en el caso batch en formatos SqlLite, TXT o
XML).
- Chivatos: Es una tcnica que permite evaluar la disponibilidad de servicios y
resulta sumamente interesante de cara a la monitorizacin del nomencltor
basndonos en los servicios que debemos estar proveyendo en todo momento.
As tenemos chivatos del Web Service, WMS, Gua Urbana municipal,
aplicativos internet y base de datos. Consisten en pequeos procesos batch que
se ejecutan temporalmente sin casi consumir recursos (cada cinco, diez, quince
minutos), de manera que si se produce alguna incidencia minimizamos los
efectos que puedan provocar en las aplicaciones conectadas al nomencltor. A
continuacin se muestra un ejemplo de cdigo relativo a la comprobacin del
WMS.


public void compAppWeb() throws Exception {
try {
boolean compText1 = false;
boolean compText2 = false;
String link = null;
link = "http://"+props.getProperty("WEB_APP_SERVER") +
props.getProperty ("WEB_APP_URI");
URL url = new URL(link);
BufferedReader in = new BufferedReader(
new InputStreamReader ( url.openConnection().getInputStream()
));
PrintStream salida = new PrintStream(new
FileOutputStream( props.getProperty ( "OUTPUT_DIR" ) +
props.getProperty ("OUTPUT_FILE_APP_WEB"),false));
String sb = "";
while (true) {
sb = in.readLine(); //
if (sb == null) {
break;
} else {
if (sb.indexOf(props.getProperty("WEB_CAD_BUSQUEDA1"))>-1)
compText1 = true;
if (sb.indexOf(props.getProperty("WEB_CAD_BUSQUEDA2"))>-1)
compText2 = true;
salida.println(sb);
}
}
in.close();
salida.close();
if (compText1 && compText2) {
ficheroLog.println(" Comprobacin Aplicacin Web: OK");
ficheroLog.println("");
checkWeb = true;


anotaMsgError("Comprobacin Aplicacin Web: OK.",null,0);
} else {
ficheroLog.println(" Comprobacin Aplicacin Web: Error");
anotaMsgError("Aplicacin web: ERROR, aplicacin contesta
incorrectamente.",null,CHEQUEO_WEB);
}
} catch (Exception ex) {
ficheroLog.println(" Comprobacin Aplicacin Web: Error");
anotaMsgError("Aplicacin web: ERROR, aplicacin no
contesta.",ex,CHEQUEO_WEB);
}
}

MANTENIMIENTO BASADO EN GEOMETRA

Sistemas de coordenadas

Ya hablamos en el captulo cuatro, al comentar los sistemas de referencia y la
problemtica de la transicin entre ellos de la necesidad de disponer, al menos de
momento de un sistema de nomencltor que reflejase la realidad en ED50 y ETRS89.
Tambin vimos la necesidad de establecer una estructura en nuestro diseo que
posibilitase nuevas modificaciones en el futuro y de cmo el S.I. del nomencltor del
municipio de Madrid estaba preparado para ello. Hablamos tambin de cmo el
Instituto Geogrfico Nacional haba puesto a disposicin de los usuarios un fichero
NTV2 con el fin de poder realizar dicha transformacin para la parte alfanumrica
georreferenciada del nomencltor. Aqu y dado que el programa suministrado por IGN
est desarrollado en VB, tambin ponemos un ejemplo en dicho lenguaje para
demostrar el modo simple en que ello puede realizarse (se ha obviado el paso entre
proyecciones por obvio, centrndonos en cmo se interacta con las utilidades
suministradas por el I.G.N.):


Rem PASO 2 USO DE ALGORITMO DE CAMBIO DE S.REF A ETRS89

Dim latitud As Double
Dim longitud As Double
Dim latitudf As Double
Dim longitudf As Double

nombre = "<rejilla>.gsb" 'Path al archivo de rejilla en formato NTV2
rl = Chr$(13) + Chr$(10) 'Definicin del retorno de lnea

'Punto a transformar

latitud = H21
longitud = H20

'latitud = 40 + 28 / 60 + 34.123 / 3600 ' Punto de latitud 4028'34.123" N pasado a
grado y decimal de grado
'longitud = -(4 + 24 / 60 + 14.123 / 3600) ' Punto de longitud 424'34.123" W pasado a
grado y decimal de grado

'Paso a segundos para entrar en la rejilla de interpolacion
latitud = latitud * 3600
longitud = longitud * 3600

'Llamada a la rutina IGN ED50>ETRS89
Call gsbread(longitud, latitud, longitudf, latitudf)

H21 = latitudf / 3600 ' Datos longitud latitud pasados por malla a ETRS89
H20 = longitudf / 3600

'Label1.Caption = "Longitud en ETRS89 " & Format(longitudf / 3600, "##.000000000") & rl
'Label1.Caption = Label1.Caption & "Latitud en ETRS89 " & Format(latitudf / 3600,
"##.000000000") & rl



Para el caso de los SIG asociados al nomencltor un posible sistema de
acomodacin a ETRS89 podra ser usar las libreras GDAL (live.osgeo.org) y usar
comandos del tipo: ogr2ogr -s_srs "+init=epsg:23030 +nadgrids=./PENR2009.gsb
+wktext" -t_srs "+init=epsg:25830 +nadgrids=null +wktext" Shape_de_destino.shp
Shape_de_origen.shp que funciona perfectamente (en este caso usando la malla
PENR2009). Tambin podemos usar otros ms enfocados a herramientas, como el
establecido a continuacin, basndonos en la plataforma ArcGis Server que es la que
se dispone actualmente en el Ayuntamiento de Madrid. Veamos cmo podra
realizarse:

A partir de la malla sped2et.gsb (es la que hemos venido usando en nuestro
nomencltor) o la ms moderna r2009v9.gsb comenzaremos nuestra tarea.
Supongamos que el directorio de entrada del servidor (o instalacin) de ArcGis es 'C: \
Program Files \ ArcGIS' (el directorio de instalacin al que nos referimos es en donde
se sitan los ficheros MXD o los nuevos MSD que denominaremos en adelante
ENTRADA). Pues bien en la ruta ENTRADA\pedata\ntv2 crearemos el directorio
Madrid, lugar en el que copiaremos el *.gsb que nos interese.

A partir de aqu podemos aplicar a un MXD concreto la transformacin o bien
dejarlo disponible para todos los MXD futuros a travs de un MXT (T=Template, es
decir plantilla). Este tipo de ficheros MSD-MXD-MXT guardan en definitiva informacin
relativa al servicio concreto MSD-MXD o a un conjunto MXT. Existe una plantilla
(template) especial denominada NORMAL.MXT, que es la genrica aplicable a todo
servicio MXD, es decir la plantilla por defecto. Si queremos que nuestra transformacin
est disponible para todo sevicio MXD modificaremos como decimos esta plantilla,
para lo cual necesitaremos usar una macro VB. Caso contrario aplicaremos
directamente al servicio MXD la transformacin. Veamos los dos casos:

Modificacin del MXT: Este paso no se dar si vamos a actuar sobre servicios
concretos, pero no queremos dejar demasiado expuesta la utilidad. En este caso nos
situaremos en ARcMap->Tools-> Macros -> Visual Basic



Una vez en el editor recorreremos el rbol hasta abrir ThisDocument dentro de
Normal.mxt->ArcMap Objects. Si el documento no est vaco ser que se han generado
toolbox propias de utilidades. En este caso se tiene que ser cauto para no eliminar
dicha informacin. En ese caso aadiremos la informacin de cdigo ms abajo
proporcionada. Por otro lado si est vaco o su informacin nos es indistinta podemos
proceder a su sustitucin por el cdigo VB que detallamos. Una vez sustituido dicho
cdigo haremos la operacin File-> Save Normal.mxt y nuestra plantilla por defecto
habr quedado actualizada.



Cdigo VB a incorporar en normal.mxt:

Private Function MxDocument_NewDocument() As Boolean
CambioDatumED50ETRS89
CambioDatumED50WGS84
End Function
Private Function MxDocument_OpenDocument() As Boolean
CambioDatumED50ETRS89
CambioDatumED50WGS84
End Function
Sub CambioDatumED50ETRS89()
' Start by getting a handle on the current FocusMap
Dim pMxDoc As IMxDocument
Set pMxDoc = Application.Document
Dim pMap As IMap
Set pMap = pMxDoc.FocusMap
' Set the input spatial reference to ED50
Dim pGCSin As IGeographicCoordinateSystem
' Dim pSpRef1 As ISpatialReference
Dim pSpRFc As SpatialReferenceEnvironment
Set pSpRFc = New SpatialReferenceEnvironment
Set pGCSin = pSpRFc.CreateGeographicCoordinateSystem(4230)
' Set pSpRef1 = pGCSin
' pSpRef1.SetFalseOriginAndUnits -180, -90, 1000000
' Set the output spatial reference to ETRS89
Dim pGCSout As IGeographicCoordinateSystem
Set pGCSout = pSpRFc.CreateGeographicCoordinateSystem(4258)
' Set pSpRef2 = pGCSout
Dim pNTv2 As IGridTransformation
Set pNTv2 = New NTv2Transformation
' A grid-based transformation has its data name set to
' dataset_<country>/<filename>
pNTv2.Name = "TRANSFORMACION_AYTO_MADRID_ED50_ETRS89"
pNTv2.GridDatasetName = "dataset_madrid/R2009V9.gsb
pNTv2.PutSpatialReferences pGCSin, pGCSout
' pNTv2.Load


' Add the transformation to the operation set
Dim pGTSet As IGeoTransformationOperationSet
Set pGTSet = New GeoTransformationOperationSet
' The Map uses IMapGeographicTransformations to access the geogtrans
Dim pMapGeo As IMapGeographicTransformations
Set pMapGeo = pMap
Set pGTSet = pMapGeo.GeographicTransformations
pGTSet.Set esriTransformForward, pNTv2
pGTSet.Set esriTransformReverse, pNTv2
'Now refresh the map
DoEvents
pMxDoc.ActiveView.Refresh
End Sub
Sub CambioDatumED50WGS84()
' Start by getting a handle on the current FocusMap
Dim pMxDoc As IMxDocument
Set pMxDoc = Application.Document
Dim pMap As IMap
Set pMap = pMxDoc.FocusMap
' Set the input spatial reference to ED50
Dim pGCSin As IGeographicCoordinateSystem
Dim pSpRFc As SpatialReferenceEnvironment
Set pSpRFc = New SpatialReferenceEnvironment
Set pGCSin = pSpRFc.CreateGeographicCoordinateSystem(4230)
' Set pSpRef1 = pGCSin
' Set the output spatial reference to WGS84
Dim pGCSout As IGeographicCoordinateSystem
Set pGCSout = pSpRFc.CreateGeographicCoordinateSystem(4326)
' Set pSpRef2 = pGCSout
Dim pNTv2 As IGridTransformation
Set pNTv2 = New NTv2Transformation
' A grid-based transformation has its data name set to
' dataset_<country>/<filename>
pNTv2.Name = " TRANSFORMACION_AYTO_MADRID_ED50_ETRS89"
pNTv2.GridDatasetName = "dataset_madrid/R2009V9.gsb"
pNTv2.PutSpatialReferences pGCSin, pGCSout
' pNTv2.Load


' Add the transformation to the operation set
Dim pGTSet As IGeoTransformationOperationSet
Set pGTSet = New GeoTransformationOperationSet
' The Map uses IMapGeographicTransformations to access the geogtrans
Dim pMapGeo As IMapGeographicTransformations
Set pMapGeo = pMap
Set pGTSet = pMapGeo.GeographicTransformations
pGTSet.Set esriTransformForward, pNTv2
pGTSet.Set esriTransformReverse, pNTv2
'Now refresh the map
DoEvents
pMxDoc.ActiveView.Refresh
End Sub

Modificacin del MXD: Para realizar este paso basta con coger cualquier capa de
servicio (cualquier mapa) o shape que sepamos que est en ED50 y abrirlo con
ArcMap. Una vez abierto, comprobaremos esta circunstancia pulsando la pestaa
view->Data Frame Properties.



Despus, pulsando el botn transformations usaremos la
TRANSFORMACION_AYTO_MADRID_ED50_ETRS89 y habremos completado la
transformacin. Es importante realizar los cambios File-> Save para que el MXD se
actualice. Por ltimo decir que podramos haber (sin crear el MXT) darle New en using
(dentro de transformations) y aplicar nuestro NTV2 (*.GSB) de forma directa, pero no
nos aparecer por defecto en la lista.

Distorsin de la malla NTv2 para la pennsula Fte: Spanish National GPS Reference Stations Network (IGN)

Sabemos de los estudios comparativos que realiz el IGN y que aquellos que en
Espaa han dado mejores resultados para la obtencin de transformaciones han sido
de mejor a peor el de mnimos cuadrados (LSC), el de superficies de mnima curvatura
(MCS - minicurv) y por ltimo rubber sheeting o mtodo de equivalencia topolgica de
ambas superficies (RS), que es el usado en Reino Unido y Suiza.



Rendimiento de los distintos sistemas de determinacin de transformacin Fte: IGN

Por ltimo decir que el sistema utilizado para transformaciones puntuales sin el
conocimiento de la rejilla ni operacin ninguna basada en homologar la
transformacin a la existente en un punto muy cercano a la incgnita, adems de ser
Universal es vlido en un rango de accin pequeo, ya que se aproximan a una
transformacin Gauss-Krger de rango corto en el que los datos de traslacin
entendemos Tx, Ty puntuales (NO ESTTICOS, SINO TENDENTES A LA POSICIN
INCGNITA) y cercanas absorben la mayor parte de la variacin de escala y rotacin
que sera precisa resultando el escalar (1+ ) por la matriz de rotacin prximo al valor
cero, quedando pues X = Tx e Y = Ty (Si Tx y Ty son calculados a partir de una X,Y muy
prximo a la de la posicin que se desea calcular).

Si alguna aplicacin exige mejores resultados en la aproximacin, se podran
considerar los parmetros de transformacin de Gonzalez-Matesanz segn la
formulacin matricial de cambio de Datum de Seeber (en el ejemplo en 3D) a travs
del modelo matricial de Bursa-Wolf:



Modelo matricial de Bursa-Wolf

Parmetros propuestos por Gonzlez-Matesanz

En la ecuacin matricial inicial de Gauss-Krger se contempla lgicamente un
solo giro, mientras que en la ecuacin de Bursa-Wolf se consideran tres al estar
hablando en un espacio tridimensional. El ICC en la transformacin 2D de la frmula
primaria establece unos parmetros para la Comunidad Autnoma Catalana que son
los siguientes:

de manera que podran establecerse otros sin ms que realizar un anlisis mnimo-
cuadrtico de tres incgnitas para la ciudad de Madrid resuelto matricialmente y en
base a puntos bien determinados.



Efectivamente, si formulamos la ecuacin de Gauss-Krger con posiciones
origen y destino conocidas:

Que matricialmente se corresponder con:

De manera que si hacemos:

Tendremos un sistema de 2 ecuaciones con cuatro incgnitas:

As que las ecuaciones de condicin sern:



Que matricialmente se podrn expresarar:

Haciendo que la matriz de residuos (diferenciales) V (Vx y Xy) resulten mnimos,
podremos resolver aplicando las reglas conocidas, as como calcular el estimador del
error medio cuadrtico:

En funcin de dicho error consideraremos cada ecuacin y su desviacin con
respecto al mismo de manera que podamos obtener una seguridad al aplicar los cuatro
parmetros a toda la zona (en principio y si estn bien determinados las X1,Y1 y X2,Y2
no habr ningn problema en poderlas aplicar a un municipio entero.

Bases de datos espaciales.

La componente espacial es intrnseca como sabemos al nomencltor, sin
embargo entre sus distintos componentes, se da la oportunidad de suministrar a la
componente espacial datos desde la componente alfanumrica o viceversa. En el caso
del Ayuntamiento de Madrid, ya vimos como los nodos de SIGMA son utilizados por la


parte alfanumrica con el fin de mantener actualizada la informacin alfanumrica en
base a un mejor anlisis SIG de los datos y otros ms que basados en sistemas SIG
proporcionan informacin alfanumrica a nuestro nomencltor y que veremos en los
siguiente apartados. Ahora veremos dos componentes que son actualizados desde la
parte alfanumrica a la espacial, aunque en el futuro se aadirn algunos otros como
la rotulacin. Actualmente los componentes actualizados son los portales y los
transportes de la ciudad de Madrid.

Ya hemos visto que diariamente se reciben las modificaciones del callejero de la
ciudad, es por ello que para mantener homognea la parte visual con la alfanumrica
dichas posiciones debern ser biunvocas, as se procede a la actualizacin diaria de la
gua urbana municipal de SIGMA. Vamos a ver un ejemplo de cmo se inserta un portal
mediante el Api java de SDE. En definitiva del conocimiento de las tablas podremos
realizar las operaciones de forma simple.

Ejemplo de insercin del dato de un portal.

package ArcSde;
import com.esri.sde.sdk.client.*;
public class Inserta_portales {
String server = "direccion.servidor.es ";
int instance = 0000;
String database = "nombre de la base de datos espacial";
String user = "usuario autorizado";
String password = "password del anterior";
try {
conn = new SeConnection(server, instance, database, user,
password);
System.out.println ("Conexin realizada a : "+ server + " ...
ok");

String[] cols = new String[3];


cols[0] = new String("COD_BDC");
cols[1] = new String("TOOLTIP");
SeLayer layer = new SeLayer( conn, "NUMERACION", "SHAPE");
cols[2] = layer.getSpatialColumn();

SeInsert insert = new SeInsert(conn);
insert.intoTable(layer.getName(),cols);
insert.setWriteMode(true);
SeRow row = insert.getRowToSet();

row.setInteger(0, 300000000);
row.setNString(1, "N 23 C");
int numPts = 1;
SDEPoint[] ptArray = new SDEPoint[numPts];
ptArray[0] = new SDEPoint(439207.0,4473735.0);
SeShape shape = new SeShape(layer.getCoordRef());
shape.generatePoint(numPts, ptArray);
row.setShape(3,shape);

insert.execute();
insert.close();
conn.commitTransaction();
conn.close();
}catch (SeException e) {
conn.rollbackTransaction();
conn.close();
}
}
}



El caso de puntos de inters se basa lgicamente en el mismo API y en los
puntos de inters que se actualizan a travs del Consorcio de Transportes de Madrid,
que contiene informacin de transportes de cercanas, autobuses urbanos e
interurbanos y metro, al que municipalmente aadimos el de paradas de taxi. El
sistema se basa en el caso de metro en un sistema que permita amoldarse a la escala
de plano, de manera que son dadas de alta por un lado las estaciones y por otro los
accesos a dicha estacin, as como las lneas que pasan por ella. Aparte se dispone de
un API para que se puedan visualizar las lneas llamando a los POI de la parte
alfanumrica del nomencltor (BDC). El resultado puede comprobarse en la siguiente
pantalla en la que se muestra un aspecto de la gua urbana municipal.

Aspecto de transportes urbanos posicionados en la gua urbana municipal



Carga de datos desde BBDDEE ajenas.

En el caso de Madrid obtenemos informacin de parcelas catastrales, as como
de cruces (los cruces en el futuro se obtendrn de la propia cartografa municipal) a
partir de la informacin de la Direccin General de Catastro (Ministerio de Hacienda y
Administraciones Pblicas), de manera que a travs de WFS es posible extraer
informacin cartogrfica (excepto Pas Vasco y Navarra que cuentan con organizacin
propia) de SIGCA (SIG Catastral) de utilidad para el Ayuntamiento. Debo decir que
como la mayora de WFS (extraccin vectorial de informacin cartogrfica, instalada en
el caso de catastro bajo GPL MapServer) tiene su acceso muy restringido. Por ello, para
usos como el que hace el Ayuntamiento de Madrid, es necesario estar registrado y ser
Administracin Pblica.

El servicio de fenmenos WFS de la DGC no es transaccional y por tanto no
tiene la opcin Transaction obligatoria ni las GetGmlOject, LockFeature o las que
podemos definir como propias (Native), por lo que segn OGC, un servicio de
fenmenos no transaccional como el visto tendr las funciones bsicas, es decir
GetCapabilties, DescribeFeatureType and GetFeature que devolver la informacin de
elementos disponibles o metadatos del servicio (FeatureType entre otros), la
descripcin concreta de un elemento (FeatureType) y sus valores para un determinado
filtro respectivamente. Todo ello en formato GML. Vamos a ver, no obstante un
ejemplo de cada llamada:

GetCapabilities (metadatos de servicio)
https://ovc.catastro.meh.es/Cartografia/WFS/ServidorWFS.aspx?delegaciondgc=28&municipiodgc=79&
service=wfs&version=1.0.0&request=getcapabilities

DescribeFeatureType (descripcin del elemento PARCELA)

service=wfs&version=1.0.0&request=decribefeaturetype&typename=PARCELA&USER=USUARIO_AUTO
RIZADO&PASSWORD=PASSWORD_AUTORIZADO


Vemos que uno de los metadatos de la salida GML es la PARCELA al invocar GetCapabilities

GetFeature (peticin de elementos PARCELA de un rea ficticia)

service=wfs&version=1.0.0&request=getfeature&typename=PARCELA&bbox=443826,4476055,443940,
4476150&USER=USUARIO_AUTORIZADO&PASSWO=PASSWORD_AUTORIZADO

En este ltimo caso aparte de todos los campos (DescribeFeatureType) del
elemento (Feature) PARCELA y su valor, obtendremos la geometra de cada polgono
de parcela en el rango seleccionado o con el filtro establecido.


Ejemplo coordinates del campo Geometry de PARCELAS mediante WFS de DGC

Un ejemplo de cmo podemos leer este tipo de ficheros en C#, por ejemplo es
el siguiente (tanto java como C# disponen de muchas utilidades para leer ficheros de
tipo GML (Geographic Markup Language):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Lectura_XML_consola
{
class Program
{
static void Main(string[] args)
{
System.Xml.XmlTextReader reader = new
System.Xml.XmlTextReader("https://ovc.catastro.meh.es/Cartografia/WFS/ServidorWFS
.aspx?delegaciondgc=28&municipiodgc=79&service=wfs&version=1.0.0&request=getcapab
ilities");
string contents = "";
while (reader.Read())
{
reader.MoveToContent();
if (reader.NodeType == System.Xml.XmlNodeType.Element)
contents += "<" + reader.Name + ">\n";
if (reader.NodeType == System.Xml.XmlNodeType.Text)
contents += reader.Value + "\n";
}
Console.Write(contents);


string pulsar = Console.ReadLine();

}
}
}

Cargadas las geometras y datos asociados en el nodo SIGMA denominado
Visualizador Urbanstico, es necesario asignar a cada portal su referencia catastral,
pues a travs de dicha relacin se tramitan expedientes municipales. Lgicamente y
salvo la carga inicial, el tratamiento se realiza exclusivamente para elementos dados de
alta o baja desde la ltima actualizacin (se realiza semanalmente) o en los que se
haya modificado la geometra. Vamos a ver un ejemplo en el que podremos ver como
se realiza un anlisis de interioricidad de punto (portal) en polgono (parcela). No
realizaremos ningn tipo de estudio terico, pues los estudios geomtricos de Jordan
en cuanto a polgonos son bien conocidos, as como otras tcnicas como la del
algoritmo radial para conocer si un punto es o no interior a un polgono. Veamos el
cdigo de ejemplo java siguiente:

Package analisisEspacial;

import com.esri.sde.sdk.client.*;
import com.esri.sde.sdk.geom.*;
import java.sql.*;
import java.text.DecimalFormat;

public class portal_parcela {
try {
String hora_inicio = "Fecha y Hora: "+(new
Timestamp(System.currentTimeMillis())).toString();

/* Conexin a SDE 1) Parte de poligonos */

String server = "servidor en el que esten las parcelas";
int instance = 0000;
String database = "Base de datos que los contenga";
String user = "USUARIO";
String password = "CLAVE";
conn = new SeConnection(server, instance, database, user, password);
System.out.println("He conectado con BD CATASTRO solicitada");
SeConnection conn1 = null;
String server1 = "servidor en el que esten los portales";
int instance1 = 0000;
String database1 = "Base de datos que los contenga";
String user1 = "USUARIO";
String password1 = "CLAVE";
conn1 = new SeConnection(server1, instance1, database1, user1, password1);
System.out.println("He conectado con BD PORTALES solicitada");

/* Select sobre la tabla (CATASTRO)*/

String tableName = "PARCELA";
SeLayer layer = new SeLayer(conn, tableName, "SHAPE");


SeSqlConstruct sqlConstruct = new SeSqlConstruct( layer.getName(),"FECHAALTA > =
20090101");

/* Select sobre la tabla (BDC) */

String tableName1 = "PORTALES";
SeLayer layer1 = new SeLayer(conn1, tableName1, "SHAPE");
SeSqlConstruct sqlConstruct1 = new SeSqlConstruct( layer1.getName(),"WHERE
OBJECTID > 0");

// Parte de campos de PARCELA

String[] cols = new String[18];
cols[0] = new String("OBJECTID");
cols[n] = <Conjunto de campos>
cols[17] = layer.getSpatialColumn();

// Parte de campos de NDPS

String[] cols1 = new String[11];
cols1[0] = new String("OBJECTID");
cols[n] = <Conjunto de campos>
cols1[10] = layer.getSpatialColumn();

// Inicio query a CATASTRO

int contador = 0;

SeQuery query = new SeQuery( conn, cols, sqlConstruct );
query.prepareQuery();
query.execute();
System.out.println("Consulta PARCELA realizada satisfactoriamente");
SeRow row = null ; /* Recojo la respuesta */

while ((row = query.fetch()) != null){

++contador;
System.out.println(" ");
System.out.println("Polgono OBJECTID = "+row.getInteger(0).intValue());
String <cualquier campo> = row.getString(n);
System.out.println("Ref. catastral : "+campo1+campo2+...+campoN);

/* Veo la parte geomtrica */

SeShape poligono = row.getShape(17);
double X,Y;
double Xm,Xn,Ym,Yn;
Xm = -999999; Ym = -9999999; Xn = 999999; Yn = 9999999;

// recorrido del polgono en partes,subpartes,puntos

int contar_xy = 0;
double[][][] points = poligono.getAllCoords();
int numParts = poligono.getNumParts();
for (int PartNo =0;PartNo<numParts;PartNo++) {
int numSubParts = poligono.getNumSubParts(PartNo+1);
for (int SubPartNo =0;SubPartNo<numSubParts;SubPartNo++) {
int numCoords =
poligono.getNumPoints(PartNo+1,SubPartNo+1);
for (int pointNo =0;pointNo<numCoords*2;pointNo+=2) {
X= points[PartNo][SubPartNo][pointNo];
Y= points[PartNo][SubPartNo][pointNo+1];
if (X>Xm){Xm=X;};
if (X<Xn){Xn=X;};
if (Y>Ym){Ym=Y;};
if (Y<Yn){Yn=Y;};
contar_xy++;


}
}
}

System.out.println(" + Num. puntos polgono : "+contar_xy);

// Inicio query a BDC

int contador1 = 0;
sqlConstruct1 = new SeSqlConstruct( layer1.getName(),"WHERE OBJECTID > 0
AND (X>"+Xn+" AND X<"+Xm+"AND Y>"+Yn+" AND Y<"+Ym+")");
SeQuery query1 = new SeQuery( conn1, cols1, sqlConstruct1 );
query1.prepareQuery();
query1.execute();
System.out.println(" Consulta "+contador+" a portales realizada
satisfactoriamente");
SeRow row1 = null ; /* Recojo la respuesta */
while ((row1 = query1.fetch()) != null){

++contador1;

// Generacin de shape punto ficticio (La entrada es multipoint)

SeShape multipunto = row1.getShape(10);
double id_x=(row1.getDouble(5).doubleValue());
double id_y=(row1.getDouble(6).doubleValue());
System.out.println(" - ObjectID,X,Y punto portal
analizado : "+row1.getInteger(0).intValue()+" * "+id_x+"
* "+id_y);
SDEPoint[] unico_punto = {new SDEPoint(id_x, id_y)};
SeShape ficticio = new SeShape(poligono.getCoordRef());
ficticio.generatePoint(1, unico_punto);

// Fin de generacin shape ficticio

/* Anlisis interioricidad */

if (poligono.isContaining(ficticio)) {
System.out.println(" Polgono :
"+row.getInteger(0).intValue());
DecimalFormat formato = new DecimalFormat("#########");
Double cod_ndpD = row1.getDouble(1);
String cod_ndp = formato.format(cod_ndpD.intValue());
System.out.println(" Punto Portal : "+cod_ndp+"
encontrado en su rea");
} // Este punto queda dentro del polgono. Coger atributos de
polgono

}
query1.close();
System.out.println("Polgono resuelto... siguiente");
}
query.close();
System.out.println("Fin de la consulta y conexin");
String hora_fin = "Fecha y Hora: "+(new
Timestamp(System.currentTimeMillis())).toString();
System.out.println("Empez a las : "+hora_inicio);
System.out.println("Termin a las : "+hora_fin);
}catch (SeException e) {

// Errores de SDE
String s1 = e.getSeError().getErrDesc();


String s2 = e.getSeError().getExtErrMsg();
String s3 = (new Integer(e.getSeError().getExtError())).toString();
String s4 = e.getSeError().getSdeErrMsg();
String s5 = (new Integer(e.getSeError().getSdeError())).toString();
String s6 = new String(",");
String errortotal =
((((((((s1.concat(s6)).concat(s2)).concat(s6)).concat(s3)).concat(s6)).
concat(s4)).concat(s6)).concat(s5));
System.out.println(errortotal);

// Saco tambien la traza
}
}
}

Por otra parte el extracto de cruces se realiza del anlisis de los subtramos de
va gracias a que el cdigo de catastro es el mismo que el de INE y podemos asociarlo a
nuestras vas, pues disponemos de la relacin. Un ejemplo de cmo despus esta
informacin se aprovecha puede verse en la siguiente pantalla, de manera que se
pueden consultar tanto los cruces de toda una calle, como de los ms cercanos a un
determinado portal, que es el caso visualizado:

Visualizacin de cruces cercanos a un portal dado en el nomencltor municipal de Madrid



Descarga de ubicaciones para navegadores

Un servicio que presta el nomencltor de la ciudad de Madrid es el de descarga
de posiciones para navegadores desde el punto de vista de puntos de inters
prestados por el municipio al ciudadano. El fin es que la informacin municipal sea
cmoda y accesible tanto para servicios internos como para el ciudadano. En la
actualidad, aparte de los portales de toda la ciudad, disponemos de los siguientes
datos descargables:

Datos descargables e iconos para navegadores en formato gpx

Adems los POI se suministran asociados a informacin del gestor de
contenidos que a travs de acceso a internet podrn consultarse (horarios, servicios,
actividades, telfonos etc.) Esta informacin es de periodicidad semanal (BDC podra
incluir cualquier POI asociado al gestor de contenidos municipal y otros como situacin
de radares fijos de la ciudad, zona de acceso restringido, poste de ticket del SER ms
cercano y cualquier otro derivado de un inters ciudadano).

Los formatos ms extendidos para inclusin de POIs en navegadores son: GPX
(topografix), GDB (Garmin), KML y KMZ (Google), PSP (Pocket Street Pushpins), MSF y
MXF (Maptech), CSV (Microsoft), WPT (OziExplorer), OV2 (TomTom) y OSM
(OpenStreetMap).



GPX (GPS Exchange format) es el formato xml de intercambio GPL ms
estandarizado, por lo que los ficheros que se descargan estn en este formato. Hoy en
da cualquier navegador incluir entre sus posibilidades la inclusin de POIs en GPX.
Adems existen algunas utilidades como GpsBabel o PoiEdit que permiten el
intercambio desde este formato a otros propietarios.

El esquema de un fichero GPX viene dado por los siguientes elementos (una
informacin detallada puede verse en http://www.topografix.com/gpx/1/1/):

Schema Document Properties
Global Schema Components
- Element: gpx
- Complex Type: gpxType
- Complex Type: metadataType
- Complex Type: wptType
- Complex Type: rteType
- Complex Type: trkType
- Complex Type: extensionsType
- Complex Type: trksegType
- Complex Type: copyrightType
- Complex Type: linkType
- Complex Type: emailType
- Complex Type: personType
- Complex Type: ptType
- Complex Type: ptsegType
- Complex Type: boundsType
- Simple Type: latitudeType
- Simple Type: longitudeType
- Simple Type: degreesType
- Simple Type: fixType
- Simple Type: dgpsStationType



Estructura jerrquica de un fichero GPX Fte: Bernhard Hiller

SINERGIAS

Vamos a tratar ahora los modos visibles de tiempo real con los que se puede
hacer uso del nomencltor y que servirn para entender las sinergias bsicas con las
que se ha de disponer en cualquier AALL de gran tamao. Evitaremos las sinergias
batch, pues entendemos ya han sido vistas en sus conceptos bsicos de traduccin-
obtencin. Del mismo modo ya han sido estudiados los elementos WMS y Gazetteer y
an ms, se profundizar sobre ellos en su uso en el ejemplo del captulo siguiente
relativo al visualizador histrico de la ciudad. As que nos centraremos en aquellas
aplicaciones Universales y de usuario o aplicacin con las que debe de contar un
nomencltor operativo y centralizado.



APLICACIONES CORPORATIVAS DE ESCRITORIO

Con respecto a la forma de interactuar con el nomencltor tenemos dos
grandes tipos de aplicacin. Por un lado aplicaciones estndar de consulta de
informacin enfocadas a un uso generalista y a la necesidad por parte de todo el
personal municipal de consultar eventualmente datos de la ciudad, as como la
obtencin de ficheros en pdf o papel para uso colectivo dentro de un negociado (ya
vista en apartados anteriores). Esto se realizar a travs del portal de intranet
municipal regido por sistemas de validacin que permiten conocer a las aplicaciones el
perfil concreto del acceso. Por otro tendremos aplicaciones que usan el nomencltor
como parte operativa de su lgica, los cuales utilizarn aplicaciones especficas del
mismo (Api y aplicaciones web emergentes), de manera que ambas formas de
interactuar las veremos separadamente, profundizando algo ms por su importancia
sobre la segunda.

Aplicaciones de consulta directa de usuarios al nomencltor.

Se centrarn bsicamente estas consultas en la informacin del nomencltor
municipal (nomencltores propio, metropolitano y estatal) al que se dar un acceso a
toda la informacin relevante y genrica de los mismos. Supongamos el caso del
nomencltor propio en el que alguien quiere consultar datos de la Avenida de la
Albufera. La pantalla mostrada ser la siguiente, en la que vemos tanto el cdigo
propio (18600), como el de INE (130), sus datos de existencia y vigencia, su inicio y fin,
as como algn dato urbanstico de inters (Absorbi a la C. Real de Madrid. Absorbido
un tramo por la C. Sierra Gador). Al mismo tiempo se nos da la posibilidad de ver la
calle o en la gua urbana o en el visor urbanstico (el perfil del usuario marcar cual es
la opcin idnea), as como una serie de posibilidades como cruces con otras calles,
puntos de inters asociados, distritos y barrios que atraviesa el vial, historia de la calle,
numeraciones y datos del nomencltor no normalizado asociados a la misma por
aplicacin.



Supongamos que queremos obtener datos de una determinada numeracin, de
manera que al pulsar la opcin correspondiente se nos da la posibilidad de ver los que
son vigentes (222 numeraciones), histricas (33 numeraciones) o ambas.



Eligiendo la opcin que nos ocupe, el sistema nos mostrar una lista de las
numeraciones de la calle con datos importantes de cada nmero en la propia pantalla,
sobre la cual a su vez podremos consultar un nmero en concreto, tal y como se
muestra con el nmero 31 de la Avda. de la Albufera que es el que se ha decidido
estudiar:

en el que podemos ver renumeraciones (se est viendo que ese nmero fue antes el
29) y toda la informacin destacada como la estadstica, el tipo de acceso (portal,
fachada etc.), coordenadas en ETRS89, parcela catastral asociada y por supuesto la
opcin de verlo en mapa. Tambin se nos posibilita el poder estudiar la historia de sus
atributos, as como la historia completa de la direccin y los cruces con calle ms
prximos e incluso un informe completo de la numeracin en pdf, tal y como se
muestra a continuacin:







Igualmente este tipo de informacin estar disponible para el nomencltor
metropolitano, a cuyos datos cartogrficos se accede a travs de la cartografa de la
Comunidad Autnoma de Madrid (sistema nomecalles). En la pantalla siguiente se est
buscando una calle mayor por todos los pueblos de la Comunidad Autnoma. La salida
es la siguiente. Por supuesto seleccionndola tendramos opciones sobre ella,
numeraciones y datos.

En este sentido nomecalles pone a disposicin de los municipios una cierta
personalizacin a travs de escudo y nombre de municipio y as por medio del cdigo
INE del mismo poder realizar una personalizacin mnima de nomecalles. En nuestro
caso personalizamos siempre con el escudo y nombre del municipio en el que se
encuentre la poblacin buscada. Si por ejemplo estamos accediendo al municipio de
Ambite, con cdigo 011 la llamada sera:



http://www.madrid.org/nomecalles/Inicio.icm?usuario=munic011&munic=011&FOTO=S

pero tambin podramos llamar a dicha poblacin personalizando como si se tratase
del callejero de Madrid (cdigo de municipio 079):

http://www.madrid.org/nomecalles/Inicio.icm?usuario=munic079&munic=011&FOTO=S

Ejemplo de personalizacin del visor WMS de nomecalles Fte: Comunidad de Madrid

Como ya sabemos, en el Ayto. de Madrid se dipone de callejeros de las
poblaciones ms importantes del Reino hasta el nivel de calle y tramo postal de


numeracin. En la actualidad es el nico subtipo de nomencltor no asociado a
cartografa y aunque dadas las caractersticas de un nomencltor municipal no es
imprescindible he estudiado algunas posibilidades bajo las opciones disponibles del
WPS y del WFS de Cartociudad, sin embargo, no acaban de responder a nuestras
necesidades. Tal vez el que ms se ajuste a nuestras caractersticas es el componente
web que puede ser aadido a una pgina de aplicacin del nomencltor e interactuar
con l de modo sencillo (http://www.cartociudad.es/VisualizadorCartografico/examples/api-test/index.html). En la
pgina siguiente hemos activado la funcin cartociudad.doSearch(albufera, 35,
Madrid) y aunque en general nos muestra informacin, tambin es verdad que muchas
veces el resultado no es el que se espera de un servicio nacional como al que
llamamos:

Problemas con los servicios de Cartociudad. Algunos servicios, por desgracia generan desconfianza en el
momento actual del proyecto Fte: IGN



Pantalla en la que se est consultando la poblacin Toledo (como vemos podemos consultar su callejero
y otras poblaciones pertenecientes a su municipio)

En lo que respecta a internet tanto la consulta del nomencltor propio como la
parte correspondiente al visualizador urbanstico y gua urbana estn disponibles para
uso ciudadano o empresas a travs del portal www.madrid.es .

APLICACIONES DE CONSULTA INDIRECTA.

Trataremos aqu el conjunto de utilidades que pone a disposicin el
nomencltor con el fin de cubrir todas las necesidades de interaccin con el mismo
desde otras aplicaciones. En su momento hablamos de la necesidad de proveer de
servicios escalables a las aplicaciones en funcin de sus necesidades. Tambin vimos
las caractersticas de otras disponibles a travs de aplicativos web con pantallas
emergentes y con un cierto grado de personalizacin. Ahora nos centraremos casi
exclusivamente en el API del nomencltor de la ciudad y sobre todo en conocer todas
las funcionalidades disponibles de cara a mostrar lo que creo que son servicios a
terceros necesarios de instaurar en sistemas como los que estamos estudiando.


Respuestas de carcter alfanumrico

Incidimos en la necesidad de escalabilidad de funciones. Vamos a ver las que
consideramos imprescindibles y el mbito en el que se localizan a travs de las
distintas API evolutivas:

Funcionalidad de validacin de datos simples

pas
Validacin del nombre de pas. Devuelve los datos de un pas, en caso de ser
encontrado, o la lista completa de datos de pases, en caso contrario.
Obtencin de datos de un pas a partir del cdigo de pas.

provincia
Validacin del nombre de provincia. Devuelve los datos de una provincia, en caso
de ser encontrada, o la lista completa de datos de provincias, en caso contrario.
Obtencin de datos de una provincia a partir del cdigo de una provincia.

poblacin
Validacin del nombre de poblacin. Devuelve los datos de una poblacin, en caso
de ser encontrada, o una lista con los datos de hasta 50 poblaciones que contengan
la cadena pasada como argumento de entrada.
Obtencin de datos de una poblacin a partir del cdigo de una poblacin.

vial
Validacin de viales (nombre de clase de vial y nombre de vial). Devuelve los datos
de un vial, en caso de ser encontrado, o una lista con los datos de hasta 50 viales
que contengan la cadena nombre de vial pasada como argumento de entrada.
Esta funcionalidad necesita como argumento de entrada un cdigo de poblacin,


para establecer si la bsqueda de viales se realiza en Madrid capital, en
poblaciones de la Comunidad de Madrid o en otras poblaciones de fuera de la
CAM.
Obtencin de datos de un vial a partir del cdigo de vial y el cdigo de poblacin.
Esta funcionalidad es vlida tanto para Madrid capital como para otras
poblaciones.
Obtencin de la lista con los datos de las clases de vial.

numero
Validacin de un nmero de vial (tipo de nmero, nmero y calificador de
nmero). Devuelve los datos de un nmero de un vial, en caso de ser encontrado,
o una lista con toda la numeracin del vial, en caso contrario. Esta funcionalidad
necesita como argumentos de entrada adicionales el cdigo de poblacin y el
cdigo de vial, para establecer si la bsqueda de nmeros se realiza para viales de
Madrid capital o para viales de otras poblaciones de la Comunidad de Madrid o del
resto de Espaa.
Obtencin de todos los datos de numeracin de un vial de Madrid capital a partir
del cdigo de vial.
Obtencin de datos de un nmero, a partir del cdigo de nmero (cdigo de ndp
para Madrid capital, cdigo de app para la Comunidad de Madrid). Esta
funcionalidad necesita como argumentos adicionales el cdigo de poblacin, para
realizar la distincin entre Madrid capital y la Comunidad de Madrid, y el cdigo del
vial al que pertenece el nmero.

distrito
Validacin del nombre de un distrito de Madrid capital. Devuelve los datos de un
distrito, en caso de ser encontrado, o una lista con los datos de todos los distritos
de Madrid.
Obtencin de los datos de un distrito, a partir del cdigo de distrito.

barrio
Validacin del nombre de un barrio de Madrid capital. Esta funcionalidad necesita
como argumento, adems del nombre de barrio a validar, el cdigo de distrito al
que pertenece el barrio. Devuelve los datos de un barrio, en caso de ser localizado,
o una lista con los datos de todos los barrios de un distrito.


Obtencin de los datos de un barrio, a partir del cdigo de barrio y del cdigo de
distrito.

local
Bsqueda de locales (escalera, planta, puerta). Esta funcionalidad realiza la
bsqueda de los datos de un local (combinacin de escalera, planta y puerta).

informacin no normalizada
Bsqueda de direcciones no normalizadas. Esta funcionalidad busca en la tablas de
base de datos de direcciones no normalizadas un registro que coincida con la
literatura de direccin pasada como entrada (desde pas hasta nmero).

nmeros postales
Bsqueda de nmeros postales. Funcionalidad que busca los cdigos postales que
corresponden a una determinada poblacin.

tramos postales
Bsqueda de tramos postales. Funcionalidad que busca en la tabla de tramos
postales el tramo postal que corresponde a una determinada poblacin, calle y
nmero.

Funcionalidad de validacin de datos complejos

direccin completa
Esta funcionalidad recibe como parmetro de entrada el conjunto de datos que
constituyen la literatura completa de una direccin, desde el nombre del pas
hasta el nmero y el local. A partir de esta informacin, se hace uso de la
funcionalidad descrita con anterioridad, para ir validando paso a paso las partes de
una direccin completa, comenzando por el nombre del pas y finalizando por el
local. La interfaz de salida de esta funcionalidad ofrece informacin de estado de


hasta donde se ha logrado validar la direccin de entrada, acceso a los datos
obtenidos a nivel de cada validacin parcial, as como informacin de seguimiento,
que se puede utilizar en sucesivas llamadas a esta funcionalidad, para continuar
validaciones a partir de un punto, y que es obligatoria como parmetro de entrada
en la obtencin de direcciones, como ya en su momento comentamos.

Funcionalidad de altas en el nomencltor (obtencin)

obtencin de direcciones
Esta funcionalidad garantiza que, a partir de la literatura completa de una
direccin (desde el nombre del pas hasta el nmero y el local) y la informacin de
seguimiento procedente de una validacin completa realizada con anterioridad, se
va a obtener un cdigo de direccin. Este cdigo de direccin puede proceder de
la correcta validacin de todas las partes de la direccin contra la base de datos de
direcciones normalizadas. Para intentar localizar este cdigo, esta funcionalidad
hace uso de la validacin de direcciones completas.
Si no se puede facilitar un cdigo nico buscando en la base de datos de
direcciones normalizadas, se hace uso de la funcionalidad de bsqueda de
direcciones no normalizadas. Si tampoco con esta funcionalidad se suministra un
cdigo nico, se procede a usar la funcionalidad de alta de direcciones no
normalizadas. Al mismo tiempo, se usa la bsqueda en nmeros y tramos
postales, para ajustar lo ms posible el cdigo postal de la direccin no
normalizada a dar de alta.

Funcionalidad de recuperacin de datos del nomencltor (traduccin)

traduccin de direcciones
Esta funcionalidad permite obtener toda la informacin disponible para una
direccin a partir de su clase y cdigo de direccin guardado por la aplicacin. Por
defecto se traducen los cdigos de direccin a sus datos y atributos ms actuales,
pero tambin es posible fijar una fecha y hora, previa a la actual, para conseguir la
informacin vigente para esa direccin en esa fecha y hora.


La funcionalidad global de traduccin de direcciones se apoya en funcionalidades
concretas, algunas de las cuales amplan la funcionalidad disponible a nivel de
partes de literatura de una direccin:

Consulta por clase y cdigo de direccin.
Consulta por clase y cdigo de direccin, para obtener todos los registros
histricos de una direccin.
Consulta por clase, cdigo de direccin y fecha y hora, para obtener los datos
histricos de una direccin en esa fecha y hora.
Consulta por clase y cdigo de direccin, para obtener todos los registros de
atributos histricos de una direccin.
Consulta por clase, cdigo de direccin y fecha y hora, para obtener los atributos
histricos de una direccin en esa fecha y hora.
Consulta de direcciones no normalizadas por cdigo de direccin no normalizada,
y opcionalmente por fecha y hora.
Consulta de locales por cdigo de local.

Funcionalidad de utilidad (Utilidades adicionales)

Consulta de los nmeros existentes en un tramo de calle por rango (par, impar,
ambos)
Bsqueda de nmeros slo en informacin normalizada.
Bsqueda de nmeros tambin en el nomencltor no normalizado.
Bsqueda de los barrios y distritos que atraviesa un vial.
Comprobacin de si un domicilio tiene un histrico que lo precede.
Bsqueda del histrico de un domicilio.
Bsqueda del tipo de dato de un portal.


Bsqueda de los cdigos de vial en donde comienza y termina otro.
Bsqueda de viales que empiezan terminan en un vial determinado.
Obtener la titularidad y la fecha de paso a histrico de un vial.
Obtener viales por titularidad.
Obtener la referencia catastral de un domicilio.
Obtener los domicilios de una determinada referencia catastral.
Bsqueda de las secciones censales de un distrito.
Bsqueda de las secciones censales de un barrio
Bsqueda de todos los domicilios con un determinado distrito y seccin censal.
Bsqueda de todos los tipos o subtipos de POI.
Bsqueda de viales que se cruzan con otro determinado.
Bsqueda de los cruces ms prximos a una direccin.
Bsqueda de vial a partir de su codigo.

Respuestas de carcter espacial

La nica utilidad que veremos cmo aplicacin web en este apartado es la de
georreferenciacin de informacin para aplicaciones que no son SIG. Efectivamente,
algunos aplicativos precisan de herramientas dinmicas para realizar esta operacin
sin tener una componente SIG en su desarrollo, pero con la necesidad de
georreferenciar datos. Es por ello que el nomencltor lo posibilita entrando bien en
global, por distrito, por barrio, por vial, por direccin o por coordenadas aproximadas.
Las pantallas emergen con la llamada (a travs de una llamada jsp window.open) y
devuelven un estado, unas coordenadas y la direccin ms cercana a las mismas a la
aplicacin origen, de manera que logramos que dicha operacin corra por cuenta del
nomencltor, consiguiendo una gran comodidad de integracin. La navegacin se hace
en este caso por controles propios de llamadas al servicio IMS de mapas.



La normalizacin de informacin puede proceder o no de una georreferenciacin Fte: MapCity

Veamos como se puede realizar una llamada a un servicio IMS y posibles operaciones
que podemos realizar sobre l.


package ejemploArcIms;

import com.esri.aims.mtier.io.*;
import com.esri.aims.mtier.model.map.*;
import com.esri.aims.mtier.model.map.Layers;
import com.esri.aims.mtier.model.map.layer.*;
import com.esri.aims.mtier.model.arcmap.Scale;
import com.esri.aims.mtier.model.map.layer.FeatureLayer;
import com.esri.aims.mtier.model.map.layer.geocode.*;
import com.esri.aims.mtier.model.envelope.Envelope;
import com.esri.aims.mtier.model.map.layer.Layer;
import com.esri.aims.mtier.model.acetate.*;
import com.esri.aims.mtier.model.map.layer.renderer.symbol.*;

/**
* @author Enrique de Dios San Romn
*/
public class Llamada_servicio_IMS {
public creaImagen() {
super();
try {
// PARAMETER DE ENTRADA (TEMA ESCALA)
// Tamao horizontal del monitor en pulgadas H1
double H1 = 2.0; //12.9;
// Resolucin horizontal del monitor en pixels H2
double H2 = 320; //1024;
// Frame en pixels deseado para la imagen H3,V3
double H3 = 320; //500
double V3 = 265; //500
// Denominador de escala a la que se desea la salida


// Mnima permitida 1000 Mxima 20000
double ESC = 5000;
// Punto a visualizar centrado
double x2 = 446582.25;
double y2 = 4476168.74;
// Salida copyright + Mayor - Menor Otro intermedio
char copyright = '+';
// ortofoto = true si se desea ortofoto, sino plano topomtrico.
boolean ortofoto = false;
// FIN DE LA PARAMETER DE ENTRADA

// Control de mxima y mnima escala

if (ESC < 100.0){ESC = 100;}
if (ESC > 200000.0){ESC = 200000;}

// Solucin de errores de incoherencia
// No movemos la vertical porque puede ser un dispositivo de V3>H3

if (H3>H2){
V3=(V3*H2)/H3;
H3=H2;
}

System.out.println("Salida horizontal pantalla (pixels):"+H3 );
System.out.println("Salida vertical pantalla (pixels) :"+V3 );

// Clculo de la mitad en unidades metros a visualizar

double longx = ((H3*((H1*0.0254)/H2))*ESC)/2.0;


double longy = ((V3*((H1*0.0254)/H2))*ESC)/2.0;

System.out.println("longx:"+longx);
System.out.println("longy:"+longy);

// Parmetros de conexin al servicio IMS
ConnectionProxy conexionPrueba = new ConnectionProxy();
conexionPrueba.setConnectionType("tcp");
conexionPrueba.setHost("00.00.00.00");
conexionPrueba.setPort(0000);

if (ortofoto) conexionPrueba.setService("ServicioOrtofoto");
else conexionPrueba.setService("ServicioVectorial");

Map map = new Map();

// Definicin de el ancho y alto de la ventana que quiero
map.setHeight((new Double(V3)).longValue());
map.setWidth((new Double(H3)).longValue());

// Conexin. No quiero leyenda.
map.initMap(conexionPrueba,0,false,false,false,false);
map.getLegend().setDisplay(false);

// Defino rea a descargar en el marco definido arriba
Envelope envelope = new Envelope(); // Define la parte que quiero sacar
envelope.setMaxX(x2+longx);
envelope.setMaxY(y2+longy);
envelope.setMinX(x2-longx);
envelope.setMinY(y2-longy);



// Quito o dejo layers a mi antojo
Layers capas = map.getLayers();
System.out.println(capas.getCount());

// Saco todas las layers en consola
for ( int i=0;i<capas.getCount();i++){
System.out.println("nmero de capa : " + i);
System.out.println(capas.item(i).getID());
System.out.println(capas.item(i).getMaxScale());
System.out.println(capas.item(i).getMinScale());
System.out.println(capas.item(i).getName());
System.out.println(capas.item(i).getType());
System.out.println(capas.item(i).hashCode());
System.out.println(capas.item(i).isVisible());
System.out.println(capas.item(i).getClass());
// parcelas es una capa esencial para visualizacin (4).
if (i == 20 || i == 21 || i == 15 || i == 7 || i == 17 || )
{ // Quita la visibilidad a la capa deseada
capas.item(i).setVisible(false);
}
}

Point point = new Point();
point.setX(x2);
point.setY(y2);

// Crea una layer acetate y le incluye el punto.
com.esri.aims.mtier.model.map.layer.AcetateLayer al = new
com.esri.aims.mtier.model.map.layer.AcetateLayer("aclayer1",null,null);
com.esri.aims.mtier.model.acetate.Acetate acetate = new
com.esri.aims.mtier.model.acetate.Acetate();
acetate.setUnits(com.esri.aims.mtier.model.acetate.Acetate.DATABASE);


acetate.setAcetateElement(point);
al.addAcetate(acetate);

//Creo un simbolo
com.esri.aims.mtier.model.map.layer.renderer.symbol.TextMarkerSymbol
tms= new
com.esri.aims.mtier.model.map.layer.renderer.symbol.TextMarkerSymbol();
com.esri.aims.mtier.model.acetate.Text text= new
com.esri.aims.mtier.model.acetate.Text();
tms.setFontColor("255,255,255"); // color del texto
tms.setFont("Times New Roman"); //Times New Roman, arial
tms.setOutline("0,0,0"); // fondo cercano (sombrilla)
tms.setGlowing("0,0,0"); //fondo lejano
tms.setFontSize(14); //tamao de letra
tms.setTransparency(50);
tms.setAngle(-0); // grados sexagesimales. Puedee usarse el negativo.
tms.setAntialiasing(true);
tms.setFontStyle("ITALIC"); // BOLD,BOLDITALIC, FULL, ITALIC,
NUMERICONLY, OUTLINE, REGULAR, UNDERLINE (Las italic salen cursivas)
text.setLabel(" Ayuntamiento de Madrid (por ejemplo)");
if (copyright == '+'){text.setLabel(" Ayuntamiento de
Madrid");tms.setFontSize(12);}
if (copyright == '-'){text.setLabel(" +madrid");tms.setFontSize(15);}
text.setSymbol(tms);
text.setX(point.getX()-longx); // Coge el punto y traslada su Y.
text.setY(point.getY()-longy+.0008);
com.esri.aims.mtier.model.acetate.Acetate acetate1 = new
acetate1.setObject(text);
al.add(acetate1);

ScaleBar escala= new ScaleBar(); // Es de la clase acetate

// la variable -valor- ser longitud de la barra en pixels
double valor = 0;


if (ESC > 999 && ESC < 3500){escala.setDistance(50);valor =
(V3*50)/(longy*2);}
if (ESC > 3499 && ESC < 10000){escala.setDistance(100);valor =
(V3*100)/(longy*2);}
if (ESC > 9999) {escala.setDistance(250);valor = (V3*250)/(longy*2);}
escala.setBarWidth(5); //ancho de barra
escala.setMapUnits(ScaleBar.METERS); // si pongo esta lnea sale en
horizontal
escala.setBarColor("255,255,255");
escala.setX(x2+longx/1.8); // Coge el objeto punto y traslada la Y un
poco arriba.
escala.setY(y2-longy+2.5);
escala.setPrecision(12);

System.out.println("escala :"+ESC);
System.out.println(valor);
System.out.println((new Double(valor)).intValue());

com.esri.aims.mtier.model.acetate.Acetate acetate2 = new
acetate2.setUnits(com.esri.aims.mtier.model.acetate.Acetate.DATABASE);
escala.setScaleUnits("meters"); //Para que salga m en la barra de escala
acetate2.setObject(escala);
al.add(acetate2);

//add acetate layer and zoom to the geocoded point extent
map.getLayers().add(al);
// fin de introduccin capa de acetato.

map.doZoomToExtent(envelope);
map.refresh(); // cojo lo que haya.

System.out.println("Ruta de devolucin imagen :"+
map.getMapOutput().getURL().toString());


//System.out.println(map.getArcXML()); // Es el XML que se genera como
llamada a IMS
ex.printStackTrace();
}
}

try {
creaImagen cliente = new creaImagen ();
ex.printStackTrace();
}
}
}

Se pretende con el anterior cdigo ver como conocer bien funciones de manejo
del servicio de mapas IMS. En ningn caso se ha pretendido crear un cdigo ptimo,
sino uno que permitiese ver cmodamente dichas funciones haciendo ms
comprensible el uso de la utilidad.



Pantalla emergente y de trabajo para lograr georreferenciar datos con ayuda

Puede ser de inters comentar aqu el uso del nuevo API para javaScript de
ArcGis Server, pues simplifica y hace ms amigable la interaccin cartogrfica de
usuario. An as, no debemos de anular los servicios IMS, que bajo nuestro punto de
vista siguen teniendo un valor fundamental, permitiendo un mayor control de usuario
y programacin que en muchos casos es necesario, facilitando en definitiva
determinadas operaciones. Veamos cmo sera una llamada a una capa determinada a
la que tengamos acceso (CAPA DE ACCESO) a travs del siguiente cdigo javascript:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Ejemplo de capa a visualizar con API REST</title>
<link href="/arcgis/rest/css" rel="stylesheet" type="text/css"/>
<style type="text/css">


@import
"http://serverapi.arcgisonline.com/jsapi/arcgis/1.2/js/dojo/dijit/themes/tundra/tundr
a.css";
</style>
<script type="text/javascript"
src="http://serverapi.arcgisonline.com/jsapi/arcgis?v=1.2"></script>
<script type="text/javascript">
dojo.require("esri.map");
var map;
function init() {
dojo.style(dojo.byId("map"), { width: dojo.contentBox("map").w + "px", height:
(esri.documentBox.h - dojo.contentBox("loginTable").h - 40) + "px" });
map = new esri.Map("map");
var layer = new esri.layers.ArcGISTiledMapServiceLayer("http://<capa a la que
tengamos acceso>");
map.addLayer(layer);
}
dojo.addOnLoad(init);
</script>
</head>

<body class="tundra">
<table id="loginTable" width="100%">
<tr>
<td id="breadcrumbs">Capa a visualizar: AQU PONER CAPA</td>
<td id="help" align="right">Ejemplo BDC usando <a
href="http://resources.esri.com/arcgisserver/apis/javascript/arcgis">ArcGIS
JavaScript API</a></td>
</tr>
</table>
<div id="map" style="margin-left:10px;margin-right:10px;width:97%;border:1px
solid #000;"></div>
</body>


Funcionalidad API geomtrica o de anlisis espacial (NO SIG)

Bsqueda de las coordenadas del inicio de un vial por cdigo de va.
Bsqueda de los datos de los nmeros de Madrid capital prximos a unas
coordenadas determinadas u otro nmero.
Bsqueda de puntos de inters (filtrables) cercanos a unas coordenadas o un
domicilio.
Bsqueda de calles prximas a unas coordenadas o un domicilio.
Comprobar si unas coordenadas estn en calzada, en acera o en parcela y
proporcionar datos asociados o confluencias.
Bsqueda del distrito y/o barrio de unas coordenadas.

Vamos a ver un ejemplo de lo sencillo que es el manejo del API del nomencltor
del Ayuntamiento de Madrid para ver los portales cercanos a una posicin X,Y y un
sistema de referencia espacial (la proyeccin se asume U.T.M.). Tengamos en cuenta
que la mayora del cdigo que aparece abajo es porque no estamos en una aplicacin
web, sino probando en consola, as que la conexin no la establezco en este caso por
datasource, lo cual si se realizar en aplicaciones web, por lo que el cdigo se reducira
al texto destacado. Es fcil darse cuenta de que la sencillez de manejo de un API es
esencial para conseguir un uso intensivo del mismo:
package probar;

import cicsepi.validacion.*;
import cicsepi.validacion.entidades.CNumero;
import cicsepi.conexion.*;

import java.util.*;
import cicsepi.excepciones.*;



public class numeros_cercanos {
try {
CConexionBDC conexionSQLSERVERSDE = new CConexionBDC();
CValidarNumeroArea numerosCercanos = new CValidarNumeroArea();
ArrayList<CNumero> lista =
numerosCercanos.cValidarNumeroArea(conexionSQLSERVERSDE, 44855242, 446841939,
25000, 25000,ED50);
for (int i=0;i<lista.size();i++){
System.out.println("Cod_VIA: " + lista.get(i).getCod_vial());
System.out.println("Cod_NDP: " + lista.get(i).getCod_ndp());
System.out.println("Distancia: " + lista.get(i).getDistancia());
System.out.println("Orientacin: " + lista.get(i).getOrientacion());
}
System.out.println("estado:"+numerosCercanos.getEstado());
}
catch (Exception e) {
}
Finaly {
if(conexionSQLSERVERSDE.isOpen()){
conexionSQLSERVERSDE.close}
}
}
}

APLICACIONES MVILES

Hemos querido poner un apartado distinto para este tipo de dispositivos, pues
reciben un tratamiento especial y bajo la perspectiva del nomencltor deben de ser
atendidos de igual manera que el resto de S.I. ya que es creciente la demanda de


informacin de los nomencltores. Ya hablamos en el apartado Descarga de
ubicaciones para navegadores en este mismo captulo de cmo se poda proporcionar
utilidad desde el nomencltor al aadir POIs a nuestros navegadores, pero debemos
avanzar ms y proporcionar al usuario utilidades cmodas de manejo. Hablamos
tambin en su momento de las caractersticas especficas y de cmo an hoy no existe
una solucin universal, pues los dispositivos se empean cada uno en llevarse el gato
al agua en cuanto a sistema operativo y lenguaje de programacin. En el Ayuntamiento
de Madrid tenemos cierta experiencia en el manejo de JavaME para el S.O. Symbian, el
pseudo-java utilizado por el SDK para Android y C# para Windows Phone, de manera
que en el momento actual se ha realizado un API especial en el S.O. Android para
manejo de aplicaciones propietarias que necesiten ejecutarse en dispositivos mviles,
que es la que en principio vamos a ver.

El sistema ideado consiste en la instalacin de un apk, que llevarn todos los
dispositivos mviles que vayan a utilizar las utilidades del callejero. El apk es invocable
en cualquier momento desde cualquier aplicacin y devuelve los datos necesarios de
validacin, comprobacin y mapa de ubicacin en su caso. Un ejemplo de una llamada
desde otro programa sera:

Button bVial = (Button) findViewById(R.id.bVial);
bVial.setOnClickListener(new Button.OnClickListener() {
public void onClick(View v) {
try {
limpiar();
Intent i = new Intent();
i.putExtra("aplicacion", " SU_APLICACION ");
i.setAction("iam.bdc.validacion.VALIDACION_MADRID");
startActivityForResult(i, VALIDACION);
}
}
});
Y la respuesta se recogera con un cdigo como el siguiente:

try {
if (resultCode == Activity.RESULT_OK){
Bundle extras = data.getExtras();
((TextView)findViewById(R.id.pais)).setText(extras.getString("paisNombre"));


((TextView)findViewById(R.id.provincia)).setText(extras.getString("provinciaNombre"));
((TextView)findViewById(R.id.pueblo)).setText(extras.getString("poblacionNombre"));
((TextView)findViewById(R.id.claseVial)).setText(extras.getString("vialClase"));
((TextView)findViewById(R.id.vial)).setText(extras.getString("vialNombre"));
((TextView)findViewById(R.id.nomApp)).setText(extras.getString("appNombre"));
((TextView)findViewById(R.id.numApp)).setText(extras.getString("appNumero"));
((TextView)findViewById(R.id.calApp)).setText(extras.getString("appCalificador"));
((TextView)findViewById(R.id.maximo)).setText(extras.getString("estadoValidacion"));
((TextView)findViewById(R.id.limiteVal)).setText(extras.getString("retornoValidacion"));
((TextView)findViewById(R.id.claseNDP)).setText(extras.getString("direccionClase"));
((TextView)findViewById(R.id.codNDP)).setText(extras.getString("direccionCodigo"));
//
((TextView)findViewById(R.id.codPais)).setText(extras.getString("paisCodigo"));
((TextView)findViewById(R.id.codProvincia)).setText(extras.getString("provinciaCodigo"));
((TextView)findViewById(R.id.codPoblacion)).setText(extras.getString("poblacionCodigo"));
((TextView)findViewById(R.id.codVial)).setText(extras.getString("vialCodigo"));
((TextView)findViewById(R.id.codVial5)).setText(extras.getString("vialCodigo5"));
((TextView)findViewById(R.id.codNumero)).setText(extras.getString("appCodigo"));
((TextView)findViewById(R.id.codDistrito)).setText(extras.getString("distritoCodigo"));
((TextView)findViewById(R.id.distrito)).setText(extras.getString("distritoNombre"));
((TextView)findViewById(R.id.codBarrio)).setText(extras.getString("barrioCodigo"));
((TextView)findViewById(R.id.barrio)).setText(extras.getString("barrioNombre"));
((TextView)findViewById(R.id.secCensal)).setText(extras.getString("seccionCensal"));
((TextView)findViewById(R.id.codPostal)).setText(extras.getString("codigoPostal"));
((TextView)findViewById(R.id.secCarteria)).setText(extras.getString("seccionCarteria"));
((TextView)findViewById(R.id.coordX)).setText(extras.getString("coordenadaX"));
((TextView)findViewById(R.id.coordY)).setText(extras.getString("coordenadaY"));
((TextView)findViewById(R.id.zonaSER)).setText(extras.getString("zonaSER"));
((TextView)findViewById(R.id.estadoHistoria)).setText(extras.getString("estadoHistoria"));
} /*else if (resultCode == Activity.RESULT_CANCELED){
} */
}

Con lo que la simplificacin para cualquier aplicativo de toda la bsqueda es
absolutamente simple, pues la validacin, las propuestas de cambio y dems
desarrollos se encuentran en la utilidad apk suministrada por el nomencltor. Las
llamadas, lgicamente se realizan va internet desde el mvil al WebService de BDC
manejado a travs de la librera KSOAP2, que fue originalmente creada para JavaME,
de manera que el manejo de todos los objetos de devolucin del WS son manejados
con total comodidad. El resto se basa en el conocimiento del interface grfico del SDK
de Android. El resultado de las pantallas emergentes que le aparecen al usuario que
llama al nomencltor dentro del mvil o la tablet es el siguiente:



Ejemplo de pantallas emergentes del nomencltor sobre un telfono mvil

Tambin est disponible la utilidad donde_estoy a la que se puede llamar, de
manera que el sistema primero por gps y luego por localizacin de antenas intenta
posicionarse en el punto en donde el usuario se encuentra, mediante un mapa sobre el
cual el usuario puede a su vez pinchar para indicar una posicin exacta como mtodo
de georreferenciacin rpida, proporcionando un sistema eficiente y rpido de
incidencias procesables en tiempo real.

Vamos a ver como sera la primera parte del cdigo de entrada a validacin y el
ejemplo de pas en cdigo java de sdk Android (se aconseja copiar el cdigo y verlo
en UltraEdit, JEdit, o algn editor de programacin para poder verlo con mayor
claridad):

package iam.bdc.validacion;

import iam.bdc.ws.CDireccionLocal;
import iam.bdc.ws.CPais;
import iam.bdc.ws.CProvincia;
import iam.bdc.ws.SalidaValidacion;
import iam.bdc.ws.WS;



import android.app.Activity;
import android.app.AlertDialog;
import android.app.Dialog;
import android.app.ProgressDialog;
import android.content.ActivityNotFoundException;
import android.content.DialogInterface;
import android.content.Intent;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.view.View;
import android.view.View.OnFocusChangeListener;
import android.view.ViewTreeObserver;
import android.view.ViewTreeObserver.OnPreDrawListener;
import android.widget.ArrayAdapter;
import android.widget.AutoCompleteTextView;
import android.widget.Button;
import android.widget.EditText;
import android.widget.ImageButton;
import android.widget.LinearLayout;
import android.widget.LinearLayout.LayoutParams;
import android.widget.RadioGroup;
import android.widget.TextView;
import android.widget.ToggleButton;

public class ValidacionBDC extends Activity {
public static final int ACTIVIDAD_VALIDAR = 1;
public static final int ACTIVIDAD_DONDE_ESTOY = 2;

//Identificadores del Dialog
public static final int DIALOG_FALTAN_DATOS = 1;
public static final int DIALOG_NO_POBLACION = 2;
public static final int DIALOG_VIAL_NO_EXISTE = 3;
public static final int DIALOG_NUM_NO_EXISTE = 4;
public static final int DIALOG_ERROR_WS = 5;
public static final int DIALOG_VALIDACION_OK = 6;
public static final int DIALOG_REDIRECCION = 7;
public static final int DIALOG_ERROR_DEFECTO = 8;
public static final int DIALOG_NO_DONDE_ESTOY = 9;

//Identificadores para realizar la llamada a la Actividad ValidacionSeleccion
public static final int SELECCION_PAIS = 1;
public static final int SELECCION_PROVINCIA = 2;
public static final int SELECCION_POBLACION = 3;
public static final int SELECCION_VIAL = 4;
public static final int SELECCION_NUMERO = 5;

//Segn la entrada el nivel de datos a validar cambia
public static final int NIVEL_PAIS = 1;
public static final int NIVEL_PROVINCIA = 2;
public static final int NIVEL_PUEBLO = 3;
public static final int NIVEL_VIAL = 4;
public static final int NIVEL_NUMERO = 5;


private int nivelSeleccionado = 0;

//Aplicacin seleccionada para hacer las consulta al WS
private String aplicacion = "";

//Componentes de cada pantalla, si no existen en la pantalla seleccionada tendrn valor nulo
private AutoCompleteTextView inPais;
private AutoCompleteTextView inProvinciaACTV; //Para la provincia existen dos variables, uno para la
entrada provincias de Espaa
private EditText inProvinciaET; //Y otro para la entrada Global. En la primera se precargan los datos para
funcionalidad autocompletar
private EditText inPueblo;
private TextView inClaseVial;
private EditText inVial;
private TextView inClaseApp;
private EditText inNumero;
private EditText inCalificador;
//Altura que va a tener el layout del botn Validar en la primera pantalla. Se obtiene una vez y despus
siempre se usa el mismo
public static int ALTURA_LAYOUT_BOTON_IMAGEN = 0;

//Copia en memoria de los datos que entran/salen de la validacin. Para as comprobar si el usuario ha
hecho algn cambio antes de aceptar
private String outPais = "";
private String outProvincia = "";
private String outPueblo = "";
private String outClaseVial = "";
private String outVial = "";
private String outClaseApp = "";
private String outNumero = "";
private String outCalificador = "";

//Ltima direccin validada
private CDireccionLocal dirValidada = null;

private boolean llamadaExterna = true;

//Valores resultado de la validacin
private boolean nivelMaximo = false;
private int nivelValidado = 0; //1 - Pas, 2 - Provincia, 3 - Poblacin, 4 - Vial, 5 - Nmero

//Dialogo redireccionamiento
private ProgressDialog dialogRedir; //Dialogo de progreso
private Handler cerrarRedir = new Handler() { //Variable que maneja el tiempo que cierra automticamente
el dialogo de progreso
public void handleMessage(Message msg) {
if (dialogRedir!=null) dialogRedir.dismiss();
}
};

/*
* Mtodo que se ejecuta cada vez que se crea la Actividad (startActivity o startActivityForResult)
*/
@Override
public void onCreate(Bundle savedInstanceState) {


super.onCreate(savedInstanceState);
try {
//La actividad tiene distintas opciones. Cada una de ellas se accede por un "action"
//distinto en el intent con el que se llama. A travs de este dato se diferencian casos:
String filtro = getIntent().getAction();

//Si el tratamiento del nombre de la aplicacin es correcto se continua con la ejecuccin
if (tratamientoNombreAplicacion(filtro)){
//Seleccin del tipo de Validacin a realizar segn el filtro seleccionado
if(filtro.equals("iam.bdc.validacion.VALIDACION_GLOBAL")){
validacionPais();
}else if(filtro.equals("iam.bdc.validacion.VALIDACION_PROVINCIA")){
validacionProvincia();
}else if(filtro.equals("iam.bdc.validacion.VALIDACION_CAM")){
validacionPueblo();
}else if (filtro.equals("iam.bdc.validacion.VALIDACION_MADRID")){
validacionVial();
}else{ //Llamada "MAIN", una ejecuccin sin una llamada desde otra aplicacin
llamadaExterna = false;
validacionVial();
}

//Aadir el botn de validar
aadirBotones(true, false, true, false, false, false, true);
//Se aade un listener al layout que almacena el botn validar para que antes de dibujarse se
ejecuta. Esto se
//hace debido a que es la nica manera de obtener su tamao, no cuando se declara sino justo
antes a dibujarse
ViewTreeObserver vto = ((LinearLayout)findViewById(R.id.layoutBotonValidar)).getViewTreeObserver();
vto.addOnPreDrawListener(new OnPreDrawListener() {
@Override
public boolean onPreDraw() {
if (ALTURA_LAYOUT_BOTON_IMAGEN==0){ //Con obtener el tamao una
nica vez es suficiente
ALTURA_LAYOUT_BOTON_IMAGEN =
((LinearLayout)findViewById(R.id.layoutBotonValidar)).getMeasuredHeight();
//La primera vez hay que hacerlo desde aqu ya que este mtodo se
ejecuta despus del "aadirBotones"
((LinearLayout)findViewById(R.id.layoutBotones)).setLayoutParams(
new LayoutParams(LayoutParams.FILL_PARENT,
ALTURA_LAYOUT_BOTON_IMAGEN));
}
return true;
}
});

//Carga en java de todos los elementos de las pantallas. Si alguno no existe ser null
inPueblo = (EditText)findViewById(R.id.tPueblo);
inClaseVial = (TextView)findViewById(R.id.tClaseVial);
inVial = (EditText)findViewById(R.id.tVial);
inVial.setOnFocusChangeListener(new OnFocusChangeListener() {
/*
* Cada vez que el vial gane el foco, se borra el contenido de la clase del vial. Debido a
que este campo no es editable, debe de haber alguna manera de permitir al usuario borrar la clase del vial despus
de haber validado una direccin. ya que si no, no puede volver atrs. Ejemplo: Escribe Alcala, en al lista selecciona
"Puerta Alcala" y si lo quiere cambiar por "Calle Alcala" no podra.


*/
@Override
public void onFocusChange(View v, boolean hasFocus) { //Cada
vez que gane/pierda foco se ejecuta el mtodo
if (hasFocus){ //Cada vez que gane el foco
inClaseVial.setText(""); //Se vaca el contenido
}
}
});
inClaseApp = (TextView)findViewById(R.id.tClaseApp);
inNumero = (EditText)findViewById(R.id.tNumero);
inNumero.setOnFocusChangeListener(new OnFocusChangeListener() {
@Override
public void onFocusChange(View v, boolean hasFocus) { //Mismo
caso que la clase del vial
if (hasFocus){
inClaseApp.setText("");
}
}
});
inCalificador = (EditText)findViewById(R.id.tCalificador);
inCalificador.setOnFocusChangeListener(new OnFocusChangeListener() { //Mismo caso que la
clase del vial
@Override
public void onFocusChange(View v, boolean hasFocus) {
if (hasFocus){
inClaseApp.setText("");
}
}
});
}else{ //Si no se muestra la pantalla de error
throw new Exception("El nombre de la aplicacin no es correcto.");
}
mostrarError(false);
}
}

protected void validacionPais() throws Exception{
nivelSeleccionado = NIVEL_PAIS;
setContentView(R.layout.validacion_pais);
((TextView)findViewById(R.id.titulo)).setText(R.string.tituloPais);
inPais = (AutoCompleteTextView) findViewById(R.id.tPais);
inProvinciaET = (EditText)findViewById(R.id.tProvincia);

//Consulta predefinida para que retorne todos los paises
SalidaValidacion salida = WS.validaDireccion("#", "provincia", "pueblo", "claseVial",
"nombreVial",
"nomApp", "numApp", "calApp", "", "", "", aplicacion);
ArrayList<CPais> paises = salida.getDatosDireccion().getPaises();

//Para que AutoCompleteTextView cargue todos los paises hay que generar un String[] y pasarle
//un layout para que el dispositivo sepa cmo debe mostrar el "tooltip" con los posibles resultados
String[] listaPaises = new String[paises.size()];
for (int i=0; i<paises.size(); i++){


listaPaises[i] = paises.get(i).getNom_pais().trim();
}
ArrayAdapter<String> adapterPais = new ArrayAdapter<String>(this, R.layout.lista_paises, listaPaises);
inPais.setAdapter(adapterPais);
}

Por otro lado comentar que gracias a estos nuevos soportes tecnolgicos
podemos ensayar nuevos campos de uso del nomencltor. As, en el caso de BDC
hemos realizado una aplicacin de rutas tursticas para Madrid que no sabemos si
acabar usndose o no (se trata de un proyecto piloto integral realizado en 2010). Una
de las misiones que tiene un nomencltor municipal es la de adelantarse a los servicios
a prestar. No siempre se acierta, pero es la nica manera de estar preparado para lo
que viene y es una recomendacin sumamente prctica de cara al desarrollo de este
tipo de sistemas. Vamos a ver su uso a travs de una pequea gua de usuario (el piloto
se realiz sobre el Madrid de los Austrias) para ver como est desarrollada la
aplicacin denominada RutaMadrid y que pueda servir como base y fuente de ideas
para otros Ayuntamientos que vean en este tipo de soluciones una oportunidad de
mejora de los servicios tursticos de su ciudad (el turismo es fuente de ingresos y
riqueza para cualquier gran Ayuntamiento: directa e indirectamente).

GUA REDUCIDA DE USO

Al ejecutar RutaMadrid lo primero que veremos ser un mensaje de bienvenida. Se ha
cogido el logo ya usado de descubre Madrid usado para este tipo de usos municipales.



Despus el sistema nos mostrar el equipo y realizaremos la seleccin del directorio en
donde se encuentran nuestros datos. Cuando llegue ese momento el sistema detectar que
hay ficheros RutaMadrid y seguir su ejecucin.

Entonces (figura izquierda) nos aparecer una pantalla inicial en la que se nos muestra
una visin genrica de lo que acontece en la ruta a visitar. Se trata de un barniz que puede ser
ledo y escuchado si se desea. Por ejemplo como nosotros no asociamos audio a este texto en
este caso no aparece. Lo suyo sera asociarlo siempre (configuracin es posible en metadatos).
A partir de ah (figura derecha) y si se desea iniciar la ruta, pulsaremos la mano Ok y caso de
que detectemos GPS en el mvil preguntaremos si se desea utilizar el apoyo GPS o no.



Se seleccione GPS o no en cualquier momento el sistema pondr a disposicin del
usuario la posibilidad de conectarse como luego veremos. Supongamos que elegimos que no,
que no deseamos movernos con GPS, sino manualmente.

Esta es la pantalla (figura de arriba) principal del aplicativo. En ella tenemos varias divisiones.

- Plano o Mapa : Un mapa en el que aparecer la ruta y los puntos a visitar. El
mapa se ir moviendo si nos encontramos en GPS y dicindonos en todo


momento nuestra posicin. Caso de no usar GPS siempre podremos
desplazarnos por el mapa a travs de las flechas del cursor especficamente
programadas al efecto viendo nuestro entorno. (El GPS gasta mucha batera y
puede que llegado un momento el usuario ya no lo necesite)
- Hitos monumentales o de inters: En la parte derecha del plano y guardando
relacin de distancias recorridas o a recorrer se encuentran los distintos hitos
que habremos de visitar durante nuestra ruta o recorrido. Son seleccionables
pudiendo cambiar en cualquier momento de hito y pudiendo visitar a priori
aquello que vamos a ver durante el recorrido. En modo GPS, estos hitos irn
cambiando de manera automticas, segn nos alejemos del hito anterior y nos
dirijamos hacia el siguiente.
- Parte inferior: Aqu se muestran los distintos eventos en los que nos
encontramos, apareciendo una imagen seleccionable en la que se nos advierte
del lugar y en el que podemos ver las distintas fotografas del lugar, video,
textos, audio y la posible conexin a GPS. Tambin en modo GPS van
cambiando a medida que nos acercamos al nuevo elemento a visitar.
- Parte superior : Conexin telefnica con elementos de inters y urgencias.

Veamos unos ejemplos de cada uno de los elementos de forma rpida:

Seleccin sobre imagen me dice dnde estoy.



Distintos monumentos y fotografas de los mismos

Seleccin de texto y audio del mismo en su caso



Cambio de posicin a travs de men de hitos derecho y nmeros de telfono disponibles en
cualquier momento para el usuario.



Una vez que el usuario ha terminado su ruta se sale de la aplicacin con el mensaje de
despedida. El sistema est pensado para usarse en cualquier lenguaje. La gran cantidad de
informacin hace de esta gua un medio muy profesional para conocer a fondo la historia de
Madrid, pudiendo coexistir con otras guas ms comerciales.



7
VISUALIZADOR HISTRICO DE
MADRID

Despus de haber realizado un estudio complejo y realmente profundo de los
nomencltores como servicios centralizados de informacin geogrfica en el caso de
un gran Ayuntamiento, vamos a ver como esos servicios en combinacin de la
tecnologa IDEE puede ser conjuntamente utilizados de forma beneficiosa para el uso
de aplicaciones no municipales de alto valor. Se ha decidido realizar un ejemplo de
visualizador histrico de la ciudad porque se trata eminentemente de una aplicacin


prctica de inters. Toda la informacin que he utilizado en Web Map Services procede
precisamente de la Comunidad Autnoma de Madrid. Me hubiese gustado poder
acceder a servicios del IGN o del Ayuntamiento de Madrid, pero en el momento actual
y hasta que se realice el nuevo WMS municipal y se mejoren los servicios de
CARTOCIUDAD los servicios ms fiables (2012) los est proporcionando la Comunidad
de Madrid. En cuanto a servicios Gazetteer, se ha utilizado el servicio web del
nomencltor (BDC) del Ayuntamiento de Madrid, el cual est plenamente operativo y
responde con eficiencia, aun no siendo un servicio OGC estndar en su configuracin
(diferente finalidad de uso).

Mi pretensin era realizar una aplicacin que pudiese demostrar que es posible
realizar herramientas externas de alto valor aadido en el mbito geomtico y/o
topogrfico a partir de los servicios de nomencltor pblicos. Cuntas veces en el
ejercicio de la profesin nos hemos visto obligados a buscar y comparar cartografa?
En el mbito de la peritacin judicial tan relacionada con la propiedad en el mbito del
registro y/o modificaciones catastrales: muchas.

El lenguaje elegido para ello ha sido C#, simplemente porque as a lo largo de
todo este estudio tenemos un abanico suficiente de ejemplos en varios lenguajes de
programacin y ello nos permite otorgarle el carcter generalista que este tipo de
investigaciones ha de tener.

Largo es el camino de la enseanza por medio de teoras;
breve y eficaz por medio de ejemplos.
(Lucio Anneo Sneca)
Un ejemplo vale ms que mil palabras
(Annimo. Refrn)



EL DESARROLLO. PUNTO DE VISTA
INFORMTICO

INTERFAZ SELECCIONADO

El interfaz de usuario utilizado ha sido el WPF (Windows Presentation
Foundation). Un desarrollo WPF permite tres tipos diferenciados usabilidad de un
desarrollo:

- EXE: La nueva tecnologa XAML (eXtensible Application Markup) permite una
independencia del API de Win32 en WPF logrando aplicaciones visuales y
multimedia altamente enriquecidas. Para darse cuenta de la potencia visual,
hemos de saber que Silverlight es un componente ms de WPF.

- ClickOnce: La implementacin ClickOnce permite publicar aplicaciones WPF en
un servidor web o en un recurso compartido de archivos de red para simplificar
la instalacin ofreciendo total compatibilidad para dicha publicacin y sus
actualizaciones (son aplicaciones standalone con aviso de actualizacin).

Esquema de implementacin ClickOnce



- XBAP: Acrnimo de XAML Browser Application. Combina las caractersticas de
aplicaciones web y aplicaciones cliente enriquecidas. Al igual que las
aplicaciones web, las XBAPs se pueden publicar en un servidor web e iniciarse
desde Internet Explorer. Al igual que las aplicaciones cliente enriquecidas, las
XBAPs pueden aprovechar las capacidades de WPF. XBAP es una nueva
tecnologa de Windows que se utiliza para la creacin de aplicaciones
dinmicas de Internet, su implementacin en un servidor web y su uso desde
un navegador como Internet Explorer ,FireFox o Google Chrome.

Las tres implementaciones posibles de un proyecto basado en WPF Fte: Microsoft

El slo hecho de esta riqueza de posibilidades de interaccin standalone-mixto-
web, as como el hecho de que Visual Studio permitiera una herramienta c# que
generase pantallas dinmicas (XAML) sin los engorrosos html+javascript de java ya era
suficientemente interesante como para usar este lenguaje. Lgicamente no todo eran
ventajas. Para quien ha programado con ventans Form interactuando con la GDI de
Windows sin preocupacin, el nuevo uso de la GUI de WPF (mucho ms restrictiva en
algunos aspectos fundamentalmente en el manejo entre ventanas y tambin ms


potente y complejo al mismo tiempo) se hace un poco desesperante en un principio,
pero si se tiene experiencia en programacin, pronto se acaba habituando, sobre todo
si ya se ha programado para web y se tiene en cuenta la lgica de dichas limitaciones.

Algunas ideas que se pueden sacar de la experiencia de programacin en .NET y
acerca de Forms, WPF y los entornos java es lo siguiente:

- Si lo nuestro ser disear herramientas para Explorer u otro navegador,
la curva de aprendizaje de WPF+C# VB ser inferior a la obtenida para
java, no obstante y en contra de lo anterior existen muchos ms
programadores java en el mercado y su coste es en general ms
econmico. Tambin es ms sencillo encontrar programadores Forms
que WPF.
- WPF no viene a echar a Forms del entorno Windows, viene a
complementarlo. Forms proviene de la plataforma 3.1 de Windows
sobre el que naci la versin 1.0 de VB. Desde entonces Forms ha
evolucionado muchsimo, pero como toda herramienta o framework de
aos, tiene el peaje de este tipo de productos que arrastran
funcionalidades de difcil adaptacin a ciertos cambios. Esto es lo que ha
pasado con la aparicin de Vista y tecnologas firmware asociadas.
- WPF frente a forms tiene una ventaja clara a la hora de incorporar 3D
(importante para nosotros), uso y sobre todo alteracin o cambio o
manejo de imgenes, video y msica. En general el uso de Media es
como ya hemos dicho anteriormente, mucho ms cmodo y sobre todo
estable.
- Forms es mucho ms ligero. En general precisa menos recursos y ello
normalmente va a implicar una mayor velocidad de clculo a igual
equipo. Si yo quiero realizar un anlisis de mmcc complejo, elegir
Forms, siempre que no me presionen a tener que verlo en navegador.
- La interaccin con XML y en general con el mundo web es superior con
WPF y aqu s que tiene un problema Forms. Un problema no prctico,
sino de tendencias. Todo depende del tipo de aplicacin.
- Actualmente Microsoft permite ciertas y cada vez ms limitadas
caractersticas Forms en WPF y viceversa aunque la propia Microsoft
indica que se trata de una mala idea y no es aconsejable. En mi caso me
he limitado a olvidarme de Forms en cdigo y centrarme en diseo
WPF. Creo sinceramente que es el futuro inmediato sobre el que se
movern los aplicativos Studio.



La eleccin (forms/wpf) ser muy relativa y siempre supeditada al uso, cliente,
tiempos, costes etc. Desde luego en el mbito de las IDEE se debe de programar en
WPF sin dudarlo, salvo para aplicaciones muy personales o de estudios concretos (y
an as). En lo que respecta a java, resulta complicado para Microsoft el imparable
ascenso de java, pero C# se est convirtiendo progresivamente en un adversario real y
en claro ascenso.

INCORPORACIN DE SERVICIOS WEB AL DISEO

En la aplicacin se usan dos tipos de servicios Web:

Por un lado el modelo de de Web Service de validacin de datos del
nomencltor (Gazetteer no OGC) del Ayuntamiento de Madrid. Se usan dos servicios
del mismo:

1. Validacin de una direccin concreta y posterior visualizacin en los mapas
elegidos.
2. Volando sobre el mapa eleccin de un punto (pinchar) y que me diga la
ubicacin a partir de las coordenadas.

Lo primero que es necesario en este tipo de servicios es disponer de la
informacin del servicio a travs de los ficheros xml de definicin para conocer el
protocolo e interaccin de datos del servicio. Este fichero se llama wsdl (web service
description language) y para el caso que nos ocupa es:

http://www-1.munimadrid.es/WSValidacionBDC/services/WSValidacionBDC/wsdl/WSValidacionBDC.wsdl

Me he encontrado a veces que a mucha gente le resulta complicado encontrar
la diferencia entre un wsdl y un xsd en un servicio web. La diferencias es clara wsdl
describe la interaccin con un WS mientras que un xsd es la definicin de datos
(esquema) de un fichero xml/gml. Por poner un ejemplo que podamos entender un
xsd sera el xml de respuesta que nos proporciona la llamada DescribeFeatureType en


un WFS. Dicho fichero nos servir para validar la salida gml de las llamadas GetFeature
de dicho servicio con respecto al mencionado esquema xsd.

http://schemas.opengis.net/ (esquemas de datos y descripcin de servicios OGC)

En el caso de nuestro WS se han usado los mtodos ValidarDireccion para el
primer caso y en el segundo getNumerosCercanos. El primero nos devuelve un objeto
SalidaOk y el segundo un SalidaXY, siendo el segundo de ellos de fcil manejo.

La forma de definir un WebService en Visual Studio 2010 es a travs del men
principal Data, AddnewDataSource. En este momento aparece una ventana en la que
introduzco la direccin del wsdl y un nombre deseado. En nuestro proyecto dicho
nombre es ServiceAytoMAD.



En lo que conozco wsdl no se ha implantado en todas las especificaciones de
servicios de OGC (lo que considero un error personalmente) y este es el caso
precisamente de WMS. Su estructura se basa ms en una serie de normas basadas en
un request denominado getcapabilities. Una versin futura del presente programa sin
duda podra afrontar esta lectura, no obstante creo al proyecto que nos ocupa,
bastaba analizar dicho xml y analizar el formato de llamada al WMS segn la layer
requerida y el sistema de referencia deseado. En nuestro caso y por comodidad hemos
seleccionado segn la nomenclatura O.G.C. el EPSSG:4230, es decir geogrficas en
ED50 a travs de las llamadas directas a los servicios request GetMap estndares
(seleccin de llamada en mtodo dameURL) de devolucin de objeto imagen.
Lgicamente la llamada obliga a definir el rectngulo perfecto en coordenadas reales y
segn la escala, centro de mapa y tamao Height,Width del objeto Image sobre el que
ubicaremos dicha respuesta. Ejemplo de llamada ser:

BitmapImage image1 = new BitmapImage();
image1.BeginInit();
imageURL1 = dameURL(int_fondo, SCPLONm, SCPLATm, SCPLONM, SCPLATM, alto_mapa_px,
ancho_mapa_px);
image1.UriSource = new Uri(imageURL1, UriKind.Absolute); // Relative se usa para
imagenes en disco
image1.EndInit();
imagen_1 = new ImageDrawing(image1, new Rect(0, 0, imagen_carto.Width,
imagen_carto.Height));

BitmapImage pertenece al espacio de nombres denominado genricamente
System.Windows.Media.Imaging que tiene la ventaja de proporcionarnos llamadas
http a travs de URI a travs de cuya clase se pueden realizar los request y response de
llamada a travs del mtodo UriSource en el cual se debe de especificar para las
llamadas http un UriKind.Absolute (Relative se usa para ficheros). Una vez generada lo
convertimos a un objeto ImageDrawing, que pertenece a System.Windows.Media y
que no es ni ms ni menos que una imagen acotada dentro de un rectngulo. Dicho


objeto se puede asignar a un objeto Image de toolbox, pero adems y esto es
importante para algunas propiedades posteriores se puede aadir a un objeto
DrawingGroup, con el cual adems de aadir las imgenes de fondo y frente,
generaremos un Storyboard para aplicar el fade o retardo correspondiente a la
visualizacin de una imagen sobre la otra. Esta funcin se realiza en el mtodo
redibuja_mapa de la clase Map_cartografia.

CLASES Y MTODOS BSICOS DEL VISUALIZADOR

Class
Mad_callejero
Esta clase se encarga de realizar todas las operaciones relativas a la bsqueda en el
callejero de la ciudad de Madrid. Hay que decir que se ha elegido dicho callejero por
estar actualizado con 24 horas de desfase respecto a los datos oficiales de la ciudad,
con lo que lo que podemos obtener incluso los nombres provisionales de las calles
todava no aprobadas por el pleno, las renumeraciones, as como el histrico a cinco
aos del mismo, obteniendo a partir del antiguo dato el nuevo.
Al ser un proyecto WPF el intercambio entre pantallas (clases pantalla) se realiza a
travs de Settings adecuando la interaccin y desactivando la posibilidad de que la
pantalla owner Mad_cartografia de Mad_callejero pueda activarla en ms de una
ocasin simultanea.

class Mad_callejero
extends Window

Attribute index
midireccion (Es parte de un objeto del tipo coordenadas junto con X,Y)
~ < midireccion : coordenadas = new coordenadas()>
data_intercambio (Como es usada una nica lista para todos los tipos de datos, discrimina el tipo de
datos de la lista). El programa est preparado para usar la misma en pas, provincia, poblacin, va y


numeracin. En el caso que nos ocupa al haber fijado las tres primeras, sabemos que slo podr tener
dos casos.
~ < data_intercambio : int>
tipovia_intercambio
~ < tipovia_intercambio : string = "">
calificador_intercambio
Los dos datos anteriores no son muy intuitivos desde el punto de vista del usuario. Se usan en segundo
plano con el fin de realizar la bsqueda en el WS de manera correcta, pero sin alteracin de pantalla.
~ < calificador_intercambio : string = "">
nombre_intercambio
Se usa para conocer que una vez llegados a un punto final (numeracin encontrada), en vez de ir a
Mad_callejero, volvemos a realizar bsqueda (Nos evitamos realizar bsquedas innecesarias)
nombre_intercambio : string = ""
~ rv
Es un objeto Visibility que especifica el estado de visualizacin de un objeto. En nuestro caso lo usamos
para el progressbar que nos especifica la altura de validacin de la direccin en la que nos encontramos.
En este caso una posible mejora sera lanzar un Thread de uso del WS con lo que la visualizacin sera
continua. Esta forma de actuar ha sido usada en Mad_Cartografia para la localizacin de direcciones
sobre mapa.
<rv : Visibility>
Operation index
Mad_callejero
boton_callejero_Click
Se ocupa este mtodo de analizar el contenido de cajas de datos y enviar la informacin al WS. El
lanzamiento del WS por su complejidad se ha preferido incluir en un bloque try-catch. La llamada a
dicho WS bsicamente es:

ServiceAytoMAD.WSValidacionBDCClient Servicio = new ServiceAytoMAD.WSValidacionBDCClient();
ServiceAytoMAD.salida respuesta_directa = Servicio.validarDireccion(ipais, iprovincia, ipueblo,
itipoVia, inombreVia, "", inumeroVia, icalific, "", "", "", "", "WSERVICE");



No obstante el anlisis de los datos es francamente complicado porque el objeto devuelto tiene que ser
analizado en rbol pudiendo contener partes del mismo o no. La verdad es que la parte de validacin de
direcciones, tal vez por lo completa que es, no es nada evidente y he echado en falta una
documentacin ms exhaustiva del mismo. Finalmente a travs de un cdigo complejo, que sin duda
con tiempo podra realizarse en una clase aparte desdoblada en mtodos para aclarar el cdigo se ha
podido llegar a un cdigo totalmente estable en cuanto a funcionamiento.
carga_lista_validar
El mtodo precisa los parmetros nmero de datos y array de valores.

carga_lista_validar(int index_dato, string[] valores)

La funcin que realiza es limpiar y despus los datos que me pasan meterlos en un objeto ListBox para
que el usuario pueda seleccionar alternativas de una lista (viales o numeraciones)

lista_validar_PreviewMouseDoubleClick
A travs de una regla switch y la variable de flujo data_intercambio que ya hemos nombrado relleno los
campos de entrada en funcin de la seleccin realizada sobre la lista para poder volver a realizar la
bsqueda si se desea.

boton_ignorar_callejero_Click
Si alguien pincha sobre el botn volver actualizar a true en Settings la variable Envio_callejero, para
que Mad_cartografa pueda saber de donde vengo y conocer a travs del artificio X=0 que se sali de la
ventana sin coordenadas ni direccin. Se cierra la ventana.

boton_vermapa_Click
Bsicamente se rellena el Settings de forma adecuada y despus se cierra la ventana

tag: namespace = WMSexplorer_Madrid
tag: import =
System;System::Collections::Generic;System::Linq;System::Text;System::Windows;System::Windows::Co
ntrols;System::Windows::Data;System::Windows::Documents;System::Windows::Input;System::Window
s::Media;System::Windows::Media::Imaging;System::Windows::Navigation;System::Windows::Shapes;Sy


stem::Xml;System::Xml::Xsl;System::IO;System::Threading;System::Windows::Threading;System::Windo
ws::Media::Animation
constraint: partial

Class
Mad_cartografia

class Mad_cartografia
extends Window

Attribute index
drag
Se trata de un objeto del tipo coordenadas (la clase de coordenadas se ha explicado poco, porque no
tiene inters desde C#) que contendr la informacin del drag del ratn, es decir la informacin de las
coordenadas al pulsar sobre el objeto Image de la pantalla (imagen_carto e imagen_carto_fondo). Se
trata de coordenadas UTM ED50 (reales)
~ < drag : coordenadas = new coordenadas()>

drag_img
Se trata de un objeto tambin coordenadas, que en este caso contiene las coordenadas de la imagen. Se
usa para jugar con variables y tambin como forma de saber si al entrar en la imagen ya venan desde
fuera con el ratn pinchado, para comenzar a arrastrar desde el margen, ya que sino, el evento
mousedown no se ejecuta sobre el evento relatio a Image.
~ < drag_img : coordenadas = new coordenadas()>

drop
Se trata del drop asociado al objeto drag. En definitiva este objeto coordenadas nos proporciona la
distancia y orientacin junto a drag de cuanto hemos movido la imagen. A partir de ese momento puedo
realizar los clculos oportunos para realizar la llamada a la imagen a travs del (los) WMS seleccionados
en Map_cartografia


~ <drop : coordenadas = new coordenadas()>

central
En toda aplicacin con parte grfica mvil que admita movimientos se debe de elegir un lugar desde el
cual aplicar movimientos. Este puede variar, pero en nuestro caso y dado que se precisan las esquinas
para llamar a los WMS lo ms apropiado era tener el centro y en funcin de los height, Witdth de las
Image y la escala, calcular el dX,dY para obtener esquinas en cada momento. Central son coordenadas
reales.
~ <central : coordenadas = new coordenadas()>

imagen_1
Es un objeto ImageDrawing sobre el que se mete el BitImage con el cual realizamos la llamada a los
WMS por url. El objeto ser el utilizado para todas las operaciones ulteriores y ser un children de los
DrawingGroup con los que realizaremos las operaciones contra los objetos Image.
~ <imagen_1 : ImageDrawing >

imagen_2
Exactamente igual al anterior pero adaptado, slo que si la anterior perteneca al fondo
(imagen_carto_fondo), esta es la que pertenece a la Image frente (image_carto)
~ <imagen_2 : ImageDrawing>

resolucion_horizontal_monitor
~ <resolucion_horizontal_monitor : double = SystemParameters.PrimaryScreenWidth>
Representa el ancho de la pantalla del equipo sobre la que se est trabajando en pixels. Su obtencin
ser realiza con:

double resolucion_horizontal_monitor = SystemParameters.PrimaryScreenWidth;



pulgadas_horizontales
Se refiere el siguiente campo <double> a las pulgadas horizontales del monitor. Se presupone pxel
cuadrado en los monitores y ha sido probado en distintos monitores con xito, aunque realmente habra
que realizar ms pruebas, an cuando creo que no hay problema alguno en la solucin adoptada al crear
realmente una relacin.

double pulgadas_horizontales = 12.9f

Las pulgadas horizontales, as como la resolucion_horizontal_monitor sirven para calcular dimensiones
de mapa, bien en coordenadas pantalla (pxel), bien en coordenadas reales de mapa. Las frmulas
usadas son:

double longx = ((ancho_mapa_px * ((pulgadas_horizontales * 0.0254d) /
resolucion_horizontal_monitor)) * escala) / 2.0d;
double longy = ((alto_mapa_px * ((pulgadas_horizontales * 0.0254d) /
resolucion_horizontal_monitor)) * escala) / 2.0d;

para las coordenadas pxel pantalla siendo ancho_mapa_px y alto_mapa_px el Width y Height de la
Image usada (image_carto e image_carto_fondo). Longx y longy representan los pixeles de pantalla
ocupados por la mitad de la zona de mapa y:

double horx_real = ((trabajo.Width * ((pulgadas_horizontales * 0.0254) /
resolucion_horizontal_monitor))* roperties.Settings.Default.Escala);
double hory_real = ((trabajo.Height * ((pulgadas_horizontales * 0.0254) /
resolucion_horizontal_monitor)) * Properties.Settings.Default.Escala);

represetar el ancho y alto total de la pantalla esperado, as como :

double x_real =
((horx_real*Convert.ToDouble(e.GetPosition(trabajo).X))/trabajo.Width)+(central.getX()/100d)-
(horx_real / 2);
double y_real = ((hory_real*(trabajo.Height-
Convert.ToDouble(e.GetPosition(trabajo).Y)))/trabajo.Height)+(central.getY()/100d)-(hory_real /
2);

x_real e y_real representan el valor homlogo de longx y longy pero en coordenadas reales .


int_fondo
Es el valor numrico correspondiente al item de Image de fondo (imagen_carto_fondo). Hay otra
variable homloga a ella que se denomina int_frente que se corresponde con la Image de frente
(imagen_carto). Se inicializa al valor 8 (ortofoto 2007) mientras que int_frente se inicializa a 7
(cartografa 1:10.000). Ambos valores sirven de uno de los parmetros de llamada al mtodo dameURL
para que se elija adecuadamente la llamada correspondiente al WMS, adems lgicamente de otros
parmetros que definen la imagen retornada. El valor de int_fondo e int_frente siempre proviene de
int_valor_seleccion, que puede verse ms abajo.

dameURL(int int_fondo, string SCPLONm, string SCPLATm, string SCPLONM, string SCPLATM, double
alto_mapa_px, double ancho_mapa_px)

El nombre que se le da al parmetro de entrada de dameURL tambin es una variable interna del
mtodo y se denomina igual, pero es simplemente circunstancial y sin trascendencia en el cdigo.
~ <int_frente : int>

string_frente
Esta variable tiene como mission recoger el valor alfanumrico del contenido visible y es correspodiente
al valor de int_frente, de manera que se puede posicionar dicho texto en los campos que se deseen en
todo momento. String_fondo acta igual slo que se corresponde con int_frente.
~ <string_fondo : string>

string_fondo
(Ver string_frente)

int_valor_seleccion
Es un valor entero que se corresponde con el orden de los elementos cartogrficos seleccionables en
pantalla (WMS). Su valor se actualiza a travs del mtodo del evento correspondiente sobre el check
(CheckBox?.Checked). Su valor actualiza el de int_fondo o int_frente dependiendo del caso y sirve
tambin para en combinacin con aquellos realizar comprobaciones como que las dos imgenes (frente
y fondo) no sean la misma, por ejemplo.


string_valor_seleccion
Es el valor correspondiente al CheckBox?.Content y tiene las mismas caractersticas que
int_valor_seleccion en cuanto a flujo por el cdigo.

selectedFileName
Contiene la direccin de WMS correspondiente a la leyenda para aquellos mapas que dispongan de ella.
Se usa para visualizar la imagen de la leyenda minimizada en la pantalla Mad_cartografia (mtodo
muestra_leyenda). Tambin sirve de parmetro para ampliar en una nueva ventana su contenido con un
scroll y hacerla visible realmente si su tamao es grande, como es el caso de las tratadas
(leyenda_mouse_down).
~ <selectedFileName : string>
Operation index
Mad_cartografia
cargatooltips
La clase Mad_cartografia en ltima instancia hace una llamada a este mtodo que se encarga de cargar
los tooltips correspondientes de los distintos objetos pantalla que por su inters deben de estar dotados
de una pequea ayuda o informacin con el fin de hacer ms cmoda su navegacin e interaccin con el
usuario. Un ejemplo de carga es:

ToolTip t3 = new ToolTip();
t3.Content = "Fija la imagen de fondo (esttica)";
button2.ToolTip = t3;

boton_Mad_callejero_Click
Realiza la llamada a la pantalla WPF de callejero (Mad_callejero). Pone todo a punto para que la
interaccin con aquella sea correcta. El cdigo es :

// Inicializo Settings de no envo desde callejero X,Y (User).
Properties.Settings.Default.Envio_callejero = false;

//Abro la pantalla de callejero


Mad_callejero pantalla_callejero = new Mad_callejero(); // objeto ventana
pantalla_callejero.Show();
pantalla_callejero.Owner = this; // As la hago hija y depende de la primera (efecto
profesional). Cascada
pantalla_callejero.Activate();
boton_Mad_callejero.IsEnabled = false;
haz_ruido(1);

dameURL
Devuelve un string url con la llamada adecuada al WMS dependiendo de los siguientes parmetros de
definicin:

dameURL(int int_fondo, string SCPLONm, string SCPLATm, string SCPLONM, string SCPLATM, double
alto_mapa_px, double ancho_mapa_px)

En donde

Int_fondo es un entero correspondiente al valor de las posibilidades de mapas disponibles
SCPLONm y SCPLATm son la longitud y latitud del punto inferior izquierda del mapa en coordenadas
geogrficas
SCPLONM y SCPLATM son la longitud y latitud del punto superior derecha del mapa en coordenadas
geogrficas
Alto_mapa_px y ancho_mapa_px son las dimensiones en pixeles de la imagen deseada para los lmites
geogrficos.

actualiza_mapa
Este mtodo es un mtodo no complicada pero si sumamente importante en el cdigo. A partir de todos
las variables y en funcin de su valor, recalcula todos los parmetros de entrada a los WMS, los llama y
genera los correspondientes BitmapImage e ImageDrawing. Por ltimo realiza una llamada a
redibuja_mapa()



redibuja_mapa
En el flujo normal de un usuario y su interaccin con la aplicacin, ste ser una de las mtodos ms
llamados de todo el programa pues en definitiva todas las interacciones con el mapa pasan por esta
clase.
El mtodo genera un DrawingGroup cuyos hijos son los objetos Drawingimage imagen_1 e imagen_2.
Dentro de dicho grupo aplica los correspondientes valores de opacidad (checkbox), retardo (slide) y
retardo (slide) para incorporarlos finalmente a los objetos Image de pantalla (imagen_carto e
imagen_carto_fondo). Por ltimo llama al mtodo regeneracin()

button1_Click
Realiza llamada a actualiza_mapa(). Este mtodo nos sirve en cualquier momento de regeneracin
desde cero de las imgenes. Es til cuando una llamada WMS no ha producido resultados por problemas
o bien cuando cambiamos el origen de datos del WMS.

Window_Loaded
Bsicamente realiza una inicializacin del contenido de algunos datos de la clase Mad_cartografa en el
momento en el que se carga la ventana. Bsicamente dichas inicializaciones son:
-Establecer los objetos Image como no redimensionables de forma automtica ( Stretch.Equals).
-Inicializo los slide slider_retardo_story (retardo imagen frente sobre fondo) y slider_escala (escala
actual) y slider_transparencia.
-Fijo zoom central (Checkbotton) y determino unas coordenadas iniciales y una escala inicial grabndo
dichos datos en settings.
-Llama a actualiza_mapa()

Window_MouseMove
Se utiliza este evento o mtodo como artificio para conocer en el caso de vuelta de la llamada a
Mad_callejero el estado de cosas y proceder en consecuencia. Ello se hace a travs de la variable de la
clase Settings

Properties.Settings.Default.Envio_callejero

Dicha variable me indica si viene de callejero. Si el anlisis de la coordenada X resulta distinto de cero
quiere decir que Mad_callejero adems me ha retornado unas coordenadas centrales. Actualizar los


settings y por ltimo realizar la llamada a inicializacin de imgenes cartogrficas mediante el mtodo
actualiza_mapa(). En cualquier caso hace un show de la pantalla Mad_cartografia, ya que a veces al
volver de otra pantalla se puede quedar en un segundo o tercer plano desagradable para el usuario.

slider_transparencia_ValueChanged
Llama a redibuja_mapa que se encarga de evaluar y calcular la variacin de transparencia y aplicar. Este
objeto pantalla tiene los valores desde 0 hasta 1 inicializados en Window_Loaded.

slider1_ValueChanged
slider1 es el nombre del objeto pantalla referido a slider_retardo_story. Se inicializa entre los valores 0-
50 con mnimos intervalos de 5 (10 = 1 segundo de tiempo). Lo nico que hace es visualizar la
informacin de tiempo y llamar al mtodo redibuja_mapa para realizar las operaciones que afecten a la
imagen en cuanto a dicho cambio.

checkBox_fija_opacidad1_Checked
Este y los tres mtodos responden a objetos checkbox de pantalla relativos a adoptar la mxima
opacidad posible del elemento imagen correspondiente a las imgenes frente (imagen_carto) y fondo
(imagen_carto_fondo) aplicable dentro de la transparencia adoptada. El que se aplica a la imagen de
fondo (CheckBox_fija_opacidad1) al no ser una imagen sobre la que se aplica transparencia fija la
imagen fondo independientemente de los valores de la de frente. True realiza la opacidad mxima.

checkBox_fija_opacidad1_Unchecked
(Ver checkbox_fija_opacidad1_Checked)

checkbox_fija_opacidad2_Checked

checkbox_fija_opacidad2_Unchecked



accion_pincho_imagen_mapa
Inicializa cualquier operacin drag-drop. Drag, drop y drag_img son objetos de la clase coordenadas, que
no se ha explicado por su simplicidad. Aqu se actualiza la informacin de drag con las label4 y 5 que
contienen las coordenadas UTM ED50 del momento. As mismo se actualiza el objeto drag_img con los
valores de los laberl2 y 3 que contienen las coordenadas imagen del momento drag.

imagen_carto_fondo_MouseDown
Llamo al mtodo accion_pincho_imagen_mapa y abro un nuevo hilo creando un objeto hiloWS al que
llamo con el constructor que contiene el objeto drag (coordenadas reales del drag en UTM). El objeto
ser realizar llamada al WS cada vez que pulsen imagen.

Muevela
Mtodo encargado de mover la imagen que se pasa. La llamada a este mtodo es :

Muevela(Image miimagen, double oldY, double newY,double oldX, double newX)

De manera que miimagen sera la Image sobre la que se desea aplicar el movimiento. oldY y oldX
representan el punto fijo correspondiente al momento drag de la imagen y que para coordenadas image
lo tengo en el objeto coordenadas drag_img. El newX, newY ser el momento actual correspondiente
que corresponder con el evento Mouse GetPosition(<Image>).X o .Y.

imagen_carto_fondo_MouseMove
Basicamente el mtodo se encarga de actualizar sobre la imagen los datos de coordenadas imagen y
coordenadas ED50 UTM y geogrficas. Adems si el botn est presionado realizo las operaciones
necesarias para llamar a Muevela(). La decisin sobre que imagen ser movida se hace en funcin del
slide de transparencia, ya que moveremos aquella imagen que sea ms intuitiva bien la imagen_carto o
la imagen_carto_fondo.

accion_mouseup_mouseleave
Calcula las nuevas imagenes centrales en funcin del drag-drop. Llama al mtodo actualiza_mapa para
regenerar los mapas en funcin del nuevo centro. Inicializa a cero el dra_img (relatvo a un posible drag.
Escomo la accin de cancelacin de drag).



imagen_carto_fondo_MouseUp
Llama al mtodo accion_mouseup_mouseleave(). Se corresponde con el drop.

imagen_carto_fondo_MouseLeave
Llama al mtodo accion_mouseup_mouseleave() slo en el caso en el que el botn estuviese
presionado. El drop se asumir como el ltimo de la Image antes de salir de su ratio.

Conviertegradosminseg
Convierte un double de entrada en grados y decimales en grados,, minutos y segundos devolviendo un
string con el contenido.

Conviertegradosminseg(double angulo)

slider_escala_ValueChanged
Diremos en primer lugar que el valor de slider_escala se inicializa en Window_Loaded entre 1000 y
25000 con saltos mnimos de 250.

slider_escala_LostMouseCapture
regeneracion
Este mtodo void se encarga de actuar sobre el contenido de los objetos Image (imagen_carto,
imagen_carto_fondo). La mayora de las veces que el flujo pase por aqu tal vez no haya alteracin sobre
el elemento pero lo que controla el mtodo es la variacin de las variables que sobre la imagen pueden
tener los objetos de accin sobre la imagen de los que dispone el usuario.
En primer lugar y en funcin del CheckBox activado como zoom 1:E ser fijado el tamao del render
sobre las Image (RenderSize).
Despus realizo el cambio de escala de las imgenes en funcin del valor del slide (slider_escala) y de la
escala de partida metiendo el resultado en un objeto ScaleTransform.
A continuacin se calcula la diferencia (incrementos en X,Y) provocado por dicho cambio de escala.
Genero dos puntos (Objetos Point) que junto a los render me determinan la posicin de la imagen.
Por ltimo genero un objeto Rectangle con dichos puntos por definicin y aplico los cambios a los
objetos Image de pantalla produciendo el efecto de zoom.


limpia_checks
En funcin de la variable valor_check que identifica el check habilitado (tal vez hubiese sido mucho
mejor manerjar los check a travs de array de check, pero bueno, identifico el check que debe de
quedar activo. De esta manera consigo que slo un tipo de informacin cartogrfica pueda ser marcada
al mismo tiempo, lo cual es fundamental para la correcta lgica y flujo del programa.

haz_ruido
A travs de un parmetro int identifico un sonido ok y un sonido wrong. Con ello para m era suficiente.
En mi visin de tener siempre en cuenta al usuario, creo que el sistema de sonidos ayuda a prestar
atencin en momentos determinados al operador. Para provocar los sonidos utilizo el Systemsound. Los
parmetros son 1 es Ok y cualquier otro error. Se podra ampliar con un montn de funcionalidad
disponible, pero a los efectos que ocupaban en nuestro caso, no era necesario ms.

checkBox?_Checked
Se rellena la variable int_valor_seleccion con el valor numrico del checkbox. As mismo
string_valor_seleccin se rellena con el string del propio check. Se realiza la llamada a limpia_checks y
por supuesto, caso de precisarlo, se asigna la leyenda a travs de la llamada muestra_leyenda(string
URL)

button2_Click
Realiza la asignacin de la imagen fondo a travs de la seleccin que haya en check?_box.

button3_Click
Realiza la asignacin de la imagen de frente a travs de la seleccin que haya en check?_box.

muestra_leyenda
Si el string de llamada al mtodo leyenda no contiene nada se hace uso del default para rellenar el
drawingImage, caso contrario, se realiza la llamada al http al WMS relativo a la leyenda del mapa
seleccionado. Hay muchos mapas, fundamentalmente aquellos que son temticos que disponen de una
extensa leyenda que resultar imprescindible para el uso del mismo. Lo he tenido en cuenta, como
puede verse. Si la leyenda es lo suficientemente poco extensa podr apreciarse bien en su imagen
reducida. No obstante, ya hemos visto que con un simple clic sobre dicha imagen reducida el programa


realiza una llamada a otra pantalla para ampliar generosamente dicha leyenda y que sea legible
cualquiera que sea el tamao de esta.

leyenda_MouseDown
Aqu se realiza la aperture de nueva pantalla explicada en el mtodo previo. Aqu se completa la pantalla
antes de ir a ella. Hago uso de StackPanel, que resulta muy til en esta circunstancia. Dado lo
interesante de esta parte del cdigo la muestro en su totalidad.

Ampliar_leyenda pantalla_leyenda = new Ampliar_leyenda();

StackPanel miStackPanel = new StackPanel();

TextBlock miTextBlock = new TextBlock();
miTextBlock.TextWrapping = TextWrapping.Wrap;
miTextBlock.Margin = new Thickness(0, 0, 0, 20);
miTextBlock.Text = "Leyenda aportada a travs del WMS";

Rectangle mirectangulo = new Rectangle();
mirectangulo.Fill = Brushes.Red;
mirectangulo.Width = 1600;
mirectangulo.Height = 5;

// Forma de meter Image en StackPanel
Image I_mi_imagen = new Image();
BitmapImage BMI_mi_imagen = new BitmapImage();

BMI_mi_imagen.BeginInit();
BMI_mi_imagen.UriSource = new Uri(selectedFileName, UriKind.RelativeOrAbsolute);
BMI_mi_imagen.EndInit();

I_mi_imagen.Stretch = Stretch.Fill; // Puede hacerse Uniform o UniformTofill
I_mi_imagen.Source = BMI_mi_imagen;


// Aado al stackpanel los elementos en el orden deseado.
miStackPanel.Children.Add(miTextBlock);
miStackPanel.Children.Add(mirectangulo);
miStackPanel.Children.Add(I_mi_imagen);

// Le meto todo el contenido al imagen_scroll definido en la pantalla
Ampliar_leyenda.xaml
pantalla_leyenda.imagen_scroll.Content = miStackPanel;

// Muesto la pantalla
pantalla_leyenda.Show();
pantalla_leyenda.Activate();

Window_Closing
Es interesante realtar aqu la diferencia entre Window_Close y Window_Closing. Window_close es
digamos el hecho del cierre de la ventana, mientras que closing nos advierte digamos de que dentro de
poco la ventana se cerrar. Esta diferencia es muy importante ya que en WPF, desde luego he podido
comprobar que si se quiere mostrar un mensaje de despedida con window_close es absolutamente
imposible, ya que la ejecucin no es posible debido al propio cierre de nuestro actual pantalla y
programa por ende. Closing permite, sin embargo, realizar alguna accin antes del cierre definitivo de
pantalla. En el caso de Forms adems ser sencillo el poder cancelar el cierre, lo cual con WPF no es tan
sencillo y de hecho en algn caso hemos visto que controlarlo es prcticamente imposible o al menos
sumamente complicado. A travs de closing mostramos una ventana de Hasta_pronto en la cual nos
despedimos del usuario haciendo el interfaz de usuario ms amigable.

tag: import =
System::Collections::Generic;System::Linq;System::Text;System::Windows;System::Windows::Controls;S


ystem::Windows::Data;System::Windows::Documents;System::Windows::Input;System::Windows::Medi
a;System::Windows::Media::Imaging;System::Windows::Shapes;System::Windows::Navigation;System::
Windows::Threading;System::Threading;System::Windows::Media::Animation;System::Media;System::
Windows::Media::Media3D
constraint: partial

hiloWS
(Ver apartado Otras clases asociadas al cdigo en el que se explica detalladamente)

latlong
Mtodo que permite obtener la longitud y latitud en coordenadas geogrficas sobre elipsoide ED50 a
partir de sus coordenadas UTM en este mismo sistema de referencia.

render_escala
Este mtodo es el encargado de devolver el render o punto de anclado del mismo, mejor dicho del
escalado (zoom + -) en funcin de los botones habilitados. Tiene un segundo mtodo encargado de
modificar las variables XY centro y settings una vez que se ha levantado el ratn del slide de escala y por
tanto todo queda OK.

Class
MainWindow

class MainWindow
extends Window

Operation index
MainWindow


Se usa un objeto DispatcherTimer para tener abierta la pantalla de presentacin durante 4 segundos.
Esto lo hace justo despus de abrir la ventana y clase Mad_cartografia. Luego pasado el timer marcado a
travs de un thread cerramos la pantalla de bienvenida.

analiza_con_timer
Aqu se cierra nicamente la pantalla.

tag: import =
a;System::Windows::Media::Imaging;System::Windows::Navigation;System::Windows::Shapes;System::
Windows::Threading
constraint: partial

Class
Hasta_pronto

Attribute index
Operation index
Hasta_pronto
Simplemente se trata de una pantalla de despedida de Mad_cartografia. Se abre esta pantalla en el
mtodo closing para hacer cmoda la interfaz de usuario.
button1_Click
Es en este momento en el que salimos de la aplicacin. En el caso Form, esto se podra usar para
cancelar el cierre (close).
accion



tag: import =
a;System::Windows::Media::Imaging;System::Windows::Shapes
constraint: partial

Class
Settings
El manejo de Settings no lo uso a nivel de mtodo. Si es interesante el conocimiento
de las variables del setting que uso o en avance de posibles ampliaciones podran
usarse y ya estn disponibles. Son las siguientes:

<Setting Name="X_callejero" Type="System.Double" Scope="User">
<Value Profile="(Default)">0</Value>
</Setting>
<Setting Name="Y_callejero" Type="System.Double" Scope="User">
</Setting>

<Setting Name="Dir_callejero" Type="System.String" Scope="User">
<Value Profile="(Default)" />
</Setting>
<Setting Name="Envio_callejero" Type="System.Boolean" Scope="User">
<Value Profile="(Default)">False</Value>
</Setting>

<Setting Name="Escala" Type="System.Int32" Scope="User">
<Value Profile="(Default)">-999</Value>
</Setting>

<Setting Name="Ancho_Real_Mapa" Type="System.Double" Scope="User">


</Setting>
<Setting Name="Alto_Real_Mapa" Type="System.Double" Scope="User">
</Setting>

<Setting Name="cancelarfin" Type="System.Boolean" Scope="User">
<Value Profile="(Default)">False</Value>
</Setting>

<Setting Name="TTipDir" Type="System.String" Scope="User">
</Setting>
<Setting Name="TTipStat" Type="System.String" Scope="User">
</Setting>
<Setting Name="TTipGeo" Type="System.String" Scope="User">
</Setting>

<Setting Name="xentra" Type="System.Int32" Scope="User">
</Setting>
<Setting Name="yentra" Type="System.Int32" Scope="User">
</Setting>

<Setting Name="control_hilos" Type="System.Int32" Scope="User">



OTRAS CLASES DE INTERS ASOCIADAS AL CDIGO

Las clases coordenadas, cuyo objetivo es interactuar con objetos que
contengan una coordenada y datos asociados, as como latlong, que se encarga de
convertir unas coordenadas UTM ED50 en geogrficas sobre el mismo datum y la clase
render_escala que posiciona en funcin de combos de la pantalla la posicin del
render sobre el que actuar el mtodo RenderTransformOrigin de una imagen no voy a
comentarlos porque, aunque muy tiles para la programacin no tienen trascendencia
desde un punto de vista de programacin en C#, por no contener tareas de
programacin avanzada o comandos especiales, sin embargo, si me parece interesante
comentar la clase hiloWS.

Class
hiloWS
Esta clase se encarga de generar hilos en los que buscar las direcciones del vuelo sobre el mapa. El
inters real y es por lo que la trato, no como a las clases arriba barnizadas sin pena ni gloria es por la
trascendencia que en programacin tiene la ejecucin de hilos (Threads). Hay dos momentos en los que
se usan hilos en este aplicacin una es un hilo en MainWindow que se encarga de un timer que llegado
un determinado momento realiza una accin (cerrar la ventana MainWindow) y otra y ms adaptada a
lo que en realidad nos encontraremos que es la que realiza la clase hiloWS. Cuando yo vuelo con el
cursor por una imagen y pincho en un momento determinado para obtener la posicin, sin duda no
puedo dejar el sistema parado hasta resolver la llamada. La solucin es un Thread que ejecute la tarea
mientras el usuario sigue trabajando con la aplicacin. Adems esa tarea para matarla, manipularla etc,
no precisar de permisos a nivel de Kernel de la mquina. Una llamada ejemplo a esta clase es

hiloWS mihilo = new hiloWS(drag.getX(), drag.getY());

Attribute index
Xentra
Yentra


Son los elementos del objeto hiloWS. Representan las coordenadas a partir de las cuales deseo obtener
la direccin ms cercana de la ciudad (en el argot histrico a esto se le llama nmero de polica). Las
coordenadas en metros
Operation index
setX
setY
Mtodos de entrada de coordenadas. Es privado y slo accesible desde el constructor hiloWS(double X,
double Y)

getX
getY
Mtodos de recogida de coordenadas. Devuelven la informacin en centmetros (La llamada al WS es en
esta unidad)

hiloWS
Aqu est el cdigo que merece la pena tratar. Cmo ejecutamos un hilo?. Simplemente definindolo y
asocindolo a un mtodo, que es el encargado de realizar la accin. Al terminar el mtodo se terminar
el Thread. En nuestro caso:

Thread t = new Thread(busca_direccion_vuelo);
t.Priority = ThreadPriority.Highest;
t.Start();

La ventaja de esta manera de proceder es que yo puedo gestionar un conjunto de [] de Threads y
lanzarlos, puedo determinar que Name tiene cada thread y a partir de l puedo realizar funciones de
comprobacin sobre los mismos del tipo

t.ThreadState = ThreadState.(Aborted, Running,Stopping.)

que me van a permitir tomar decisions. Por ejemplo, si el pool est muy lleno puedo dedicarme a
eliminar (en nuestro ejemplo t.Abort) o realizar tareas de no enviar ms peticiones hasta que no se


resuelvan las existentes. En el cdigo que nos ocupa no hemos afinar al mximo, no obstante en
cualquier tarea comercial sera preciso.

busca_direccion_vuelo
Es un void que realiza la llamada al WebServices de obtencin de direccin. Un ejemplo bsico de
llamada es el siguiente.

ServiceAytoMAD.WSValidacionBDCClient Servicio_2 = new ServiceAytoMAD.WSValidacionBDCClient();
ServiceAytoMAD.salidaXY respuesta_asincrona = Servicio_2.getNumerosCercanos(X, Y, margen,
margen, booleano, usuario);

El anlisis de los datos devueltos es trivial en este caso. No tiene nada que ver con el caso de
direcciones, cuyo objeto es intratable.

DIAGRAMA DE CLASES FUNDAMENTALES

A partir de Metamil para generar el C#doc y diagramas de clases que me ha permitido
exportar el fichero xmi (UML) que he utilizado, entre otras cosas para documentar este
proyecto. Adems se pueden sacar diagramas de clases muy fcilmente y es
francamente cmodo e intuitivo. En la pgina siguiente y sin ms pretensiones que las
de esta prctica vemos una visin parcial del resultado ejemplo de esta misma
prctica.



c_ApplicationSettingsBase
c_Settings
{namespace=WMSexplorer_Madrid::Properties}
IComponentConnector
[from System::Windows::Markup]
Window
[from System::Windows]
WSValidacionBDC
ClientBase
[from System::ServiceModel]
IClientChannel
[from System::ServiceModel]
MainWindow
[from DesignView]
Hasta_pronto
[from DesignView]
Ampliar_leyenda
[from obj::x86::Debug]
{namespace=WMSexplorer_Madrid}
MainWindow
[from obj::x86::Release]
Mad_cartografia
Mad_callejero
Hasta_pronto
Ampliar_leyenda
WSValidacionBDCClient
[from Service References::ServiceAytoMAD]
{namespace=WMSexplorer_Madrid::ServiceAytoMAD}
WSValidacionBDCChannel
salidaOk
NUMEROXY
NUMEROSXY
salidaXY
WSValidacionBDC
{bind <WMSexplorer_Madrid::ServiceAytoMAD::WSValidacionBDC>}


MANUAL. BREVE GUA DE USO

El visualizador histrico urbanstico es una herramienta ideada a fin de ver las
posibilidades de un entorno cartogrfico basado en servicios web map y servicios web
de datos. Con dicho fin se ha enfocado una herramienta al mbito del municipio de
Madrid, para lo cual se usan map services de la Comunidad de Madrid y servicios web
del Ayuntamiento de la capital, con el nico fin de poder ver una de las mltiples
posibilidades de estos servicios de cara a usuarios terceros.

La herramienta WMSExplorer_Madrid permite realizar estudios visuales
comparativos entre los aos 1927 y 2007 a travs del siguiente material cartogrfico:
siete ortofotos, 2 temticos actuales y un topogrfico de gran escala. Todo l proviene
de servicios de la CAM. Adems existen otras utilidades enfocadas al estudio,
identificacin o localizacin de una zona concreta a estudiar.

Arrancaremos el programa pinchando dos veces en el icono :

En ese momento se cargarn dos pantallas, una la propia del aplicativo y otra la de
presentacin, en la cual se presentan anagramas de la CAM, Ayuntamiento en calidad
de proveedores de servicios utilizados y el logotipo de la Universidad de Salamanca
como artfice del centro de estudios en el mbito del cual se desarrolla el estudio.


La herramienta en s misma es muy sencilla de usar y bastan cinco minutos para
dominar su manejo sin ningn problema. Esto es una de las cuestiones ms importante
de un aplicativo. Para m este siempre debe de cumplir las premisas principales del
tipo:

- Cumple la funcionalidad completa para la que se dise
- Mejora la curva de aprendizaje del aplicativo previo (si lo hubiera)
- El usuario tiene una percepcin positiva frente al nuevo entorno.
- La comodidad y facilidad de la tarea a realizar es mejor que la previa.

Por mi parte, creo que la uno y la cuatro estn cumplidos y es por ello que se ha
intentado minimizar el uso de pantalla. El hecho de abrir alguna nueva ha sido ms
objetivo de mi curiosidad innata ms que til, no obstante un entorno WPF es
bastante diferente a un entorno Forms en lo que es este tipo de manejos, de manera
que su uso es bastante ms complejo, como ya dijimos en su momento.



Creo que la mejor manera de abordar la pantalla es ir viendo las distintas
funcionalidades. Dentro de la pantalla general a travs de la identificacin numrica de
los sub-apartados de la misma:

1

En este panel aparecen los distintos mensajes relacionados con la identificacin sobre
plano. Guarda una estrecha relacin con los sub-apartados 2 y 10. Por ejemplo Al
pulsar sobre el plano , WMSExplorer_Madrid investiga la direccin municipal ms
cercana. En este caso y como vemos la direccin oficial de la escuela es C/ Provisional
Politcnica de Vallecas Cuatro, n 2.



2

Estos tres botones sirven para modificar la informacin aparecida en el panel. Por
defecto, al entrar en el programa se activar el primer botn que es el que se ha
previsto como ms usada. Si pulsamos el botn dos aparecer la informacin asociada
al distrito, barrio y seccin censal y en el caso del tercer botn la distancia y
orientacin desde el punto seleccionado sobre el mapa al portal ms cercano, tal y
como podemos ver en la pantalla siguiente:

Estos dos botones no contienen informacin en el caso en que estemos sobre la regla
(10)



3

Contiene los mapas de fondo y frente seleccionados a travs de los botones 12. La
zona visualizada depender de la funcin activa.
Sobre los mapas se pueden realizar las funciones de arrastre convencionales para
movernos sin alterar la escala a travs del plano. Tambin podemos, como hemos visto
antes pinchar sobre un punto para obtener la direccin ms cercana. Es importante
resaltar que en el arrastre se mover la imagen tericamente ms visible a partir del
dato de transparencia (5) que haya en ese momento.

Movindonos sobre su superficie siempre podremos ver las coordenadas imagen y las
coordenadas UTM y geogrficas en el sistema ED50.

4

Fija a travs de esta barra de deslizamiento el tiempo que tarda en aparecer la imagen
secundaria sobre la primaria. Deberemos tener ajustado previamente la barra de
desplazamiento de transparencia (5) y en su caso fijar la opacidad mxima de la
imagen secundaria (7), hasta ajustar bien el efecto de visualizacin, con el fin de
realizar anlisis sobre cambios en el urbanismo de la ciudad y apreciarlos lo mejor
posible. El retardo provoca una aparicin progresiva de la imagen. Dicho retardo
puede ir desde cero (valor por defecto) hasta cinco segundos.

5

Se fija aqu el grado de transparencia de la imagen secundaria sobre la principal. Por
defecto la transparencia es nula, de manera que la imagen de fondo no se ve.
Ajustando en combinacin con (7) realizaremos un ajuste adecuado de acuerdo a lo


que queramos observar. En la imagen vemos la apariencia de la ortofoto de 1946 con
el topogrfico en la zona seleccionada.

6

Esta casilla, al activarla hace visible slo la imagen principal. Resulta til muchas veces
fijar las barras de desplazamiento de transparencia y retardo a cero, de manera que
aparezca la imagen secundaria totalmente ntida. Activando y desactivando esta casilla
podemos ver cambios muy ntidamente en algunas ocasiones sobre el urbanismo de la
ciudad. El efecto, por ejemplo entre la ortofoto de 1946 y 1961-67 en los alrededores
del estadio del Rayo Vallecano son los siguientes:



7

El fijar opacidad mxima en la imagen secundaria est ntimamente relacionado con el
efecto de transparencia de esta sobre la primaria. Muchas veces al establecer una
transparencia entre las dos imgenes nos encontramos en un punto ideal, pero en el
que no queremos anular la nitidez de la imagen primaria, sino darle un poco ms de
visibilidad a la primaria. Esto se consigue con la activacin de esta casilla. En la imagen
vemos un ejemplo de transparencia y despus esa misma transparencia a la que se le
ha aplicado el efecto de opacidad mxima de imagen secundaria en transparencia. En
la imagen una zona del PAU de Sanchinarro en los ochenta y en la actualidad (2007)



8

El refresco de pantalla, en general es automtico en las funciones que as es lgico.
Hay otras en que deberemos de realizar nosotros el refresco. Por ejemplo cuando
modificamos las imgenes de fondo y frente (12) y queremos seguir en la misma zona,
deberemos de pulsar este botn. Igualmente si queremos ver el efecto de retardo una
y otra vez usaremos este mismo botn. Tambin es til en alguna ocasin en que una
de las imgenes no aparece para realizar nuevas llamadas sobre el WMS, no obstante
en este sentido suele suceder que el servicio durante un tiempo no estar disponible.

9

El panel contiene todos aquellos servicios WMS disponibles. Si esta fuese una
herramienta tcnica de mbito real, los servicios deberan de poder cambiarse a travs
de ficheros de configuracin, de manera que pudisemos ampliar y/o cambiar los
distintos WMS a los que deseamos llamar en funcin de la orientacin de nuestro
estudio comparativo urbanstico. En nuestro caso esto es un boceto de un proyecto
real, de manera que en la lista aparece lo que podra ser aquella seleccin realizada
para un mbito concreto deseado. Los WMS disponibles son

1. Ortofoto de 1927
2. Ortofoto de 1946
3. Ortofoto de 1961-67
4. Ortofoto de 1975
5. Ortofoto de 1984
6. Ortofoto de 1991
7. Ortofoto de 2007
8. Cartografa 1:10.000
9. Temtico de usos de suelo
10. Temtico de vegetacin

Debajo de este panel y para los mapas temticos, tenemos la informacin sobre la
leyenda. Si sta es reducida, podr verse directamente en l, no obstante, como es


nuestro caso, ambas leyendas son extensas por lo que podremos pinchar sobre dicha
imagen aparecindonos una nueva ventana WPF con la informacin ampliada. En el
ejemplo podemos ver este hecho:

10

Esta herramienta permite la medicin sobre el mapa de distancias y superficies. La
superficie siempre se va calculando considerando el cierre con el primer punto
seleccionado. La nica limitacin de esta herramienta es que toda la longitud o
superficie a medir debe de encontrarse dentro del marco visualizado en el momento
de comenzar a medir. Las opciones sobre la identificacin del portal cercano a los
puntos marcados se anulan mientras la regla est disponible.

Por ejemplo en la imagen siguiente vemos que estamos en la zona de la Glorieta de
Carlos V y deseamos realizar una medicin aproximada de la antigua estacin de
Atocha. Vemos que efectivamente su permetro es de unos 508 metros y su superficie
de 1.4 hectreas aproximadamente. Como datos auxiliares aparecen el nmero de
puntos tomados y el coeficiente de anamorfosis para la proyeccin cartogrfica UTM


en el ltimo punto tomado. Vemos tambin que en lugar de la regla, aparece el
smbolo:

que nos servir para anular la operacin en cualquier momento y volver al modo de no
medicin, en cuyo momento volver a aparecer en pantalla la regla, en lugar del
crculo rojo y el aspa de cancelacin.

11


Al pulsar este botn se accede a una nueva pantalla, tal y como se muestra, en la cual
podremos buscar calles dentro del callejero actual e histrico de no ms de cinco aos.
El sistema incluye topnimos de la ciudad. Para ello se realiza una llamada a la Base de
datos ciudad del Ayuntamiento de Madrid a travs de un Web Service.

En el ejemplo siguiente podemos ver que en el vial Logroo (slo hay un vial con el
nombre Logroo en Madrid), el sistema nos propone la numeracin deseada. Como
podemos ver caso de haberse producido renumeraciones o cambios de calle de una
direccin, el sistema nos informa de este hecho. Por ejemplo el portal de la Av.
Logroo n 183 es el actual C/ Baha de Cdiz, n 2.



De igual manera, el sistema nos ofrece posibilidades si el nombre de la calle es
ambiguo para el sistema. Por ejemplo tecleando Alfonso tendremos:

que es el resultado de los topnimos municipales o viales con el nombre Alfonso del
municipio de Madrid.

En el momento que elegimos una calle que dispone de coordenadas el botn Ver
cartografa se activar y puede ser en alguna circunstancia de que hasta que no
lleguemos a una numeracin no tengamos disponible el botn. Si lo pulsamos se
cerrar la pantalla de consulta Mad_callejero y se nos presentar el elemento elegido
en el centro de la pantalla general de la aplicacin.

Nota.- En algunos casos el vial seleccionado (ocurre a veces con algunos topnimos) no
disponemos de informacin de coordenadas a travs del Web Service, por lo que el
botn Ver cartografa no estar activo. En ese caso tambin el sistema advierte de
este hecho, tal y como muestra la pantalla siguiente:


12

Estos dos botones, como los tiptool correspondientes indican sirven para fijar la
imagen deseada tanto para el fondo como para el frente cartogrfico elegido. Por
defecto la imagen primaria es la ortofoto de 2007 y la secundaria o frente es el mapa
cartogrfico 1:10.000.

La manera en que pueden ser modificados es seleccionando a travs de las casillas a la
izquierda (9) el elemento deseado para luego pulsar sobre el botn en funcin de
dnde lo deseemos situar si en el fondo o en el frente (primaria o secundaria). El
sistema no permite tener el mismo fondo topogrfico en ambas, lo cual se advertir
con un sonido acstico de error.



Una vez hecha esta operacin en el siguiente movimiento realizado sobre el mapa se
actualizar la cartografa. Si se desea ver instantneamente deberemos pulsar un
refresco de imagen a travs del botn (8)

En cualquier momento se puede salir de esta pantalla, pulsando el botn cerrar o bien
el aspa de Windows. Es importante resaltar, que mientras esta ventana est abierta el
botn de la pantalla general de llamada a callejero se desactiva para que no se abran
varias pantallas concurrentemente.

13

Punto fijo 1:E intenta hacer mencin al punto de anclaje deseado ante un cambio de
escala sobre la imagen. Normalmente los sistemas convencionales fijan en el centro
cualquier cambio de escala realizado, en nuestro caso a partir de la barra de
desplazamiento al efecto (14). En la aplicacin WMSexplorer_Madrid esta es la
posicin por defecto, no obstante podemos elegir esa posicin o cualesquiera de las
esquinas del mapa. Esto es sumamente til en muchas operaciones de zoom y que
normalmente, no sabemos por qu no incorporan otros sistemas.

En el ejemplo siguiente vemos que hemos elegido la esquina superior derecha como
punto de anclaje y vemos como se comporta un zoom, sea + al realizar la operacin
de cambio de escala con la barra de desplazamiento de escala. (El ejemplo es sobre la
misma imagen en zoom (menor escala) y zoom + (mayor escala)

14

Esta barra de desplazamiento permite modificar la escala de la cartografa visualizada a
partir del punto de anclaje marcado (13). El abanico de escalas disponible es desde
1:1000 a 1:25.000 que es el que resulta til para detalles y vistas de pjaro en un
anlisis comparativo de carcter urbanstico como el presentado.


15

En este panel se muestran las coordenadas del ratn a su paso por la cartografa,
pudiendo as identificar las coordenadas de un punto cualquiera del mismo. Estn
disponibles en proyeccin UTM y geogrfica para el elipsoide ED50. En la parte
superior izquierda de este panel, podemos ver tambin, por si fuese necesario para
alguna operacin de pixelado sobre la imagen y en posibles futuras ampliaciones del
programa las coordenadas pantalla (pixel imagen-pantalla) de ese mismo punto para la
imagen.


Por ltimo comentar que para desarrollar esta aplicacin, tan slo ha sido
necesario Visual Studio Express 2010 (C#) de cara a la programacin

Herramientas utilizadas para realizar este trabajo de asignatura. Metamil para generar
el C#doc y diagramas de clases que me ha permitido exportar el fichero xmi (UML) que
he utilizado, entre otras cosas para documentar este proyecto. En cuanto a las dudas a
nivel programacin se han resuelto con los apuntes de la UPM de la asignatura
Anlisis y programacin C# [Juan Jos Arranz]) y la consulta de Microsoft MSDN C#
Visual Studio 2010 (internet).

CDIGO FUENTE Y EJECUTABLES

Se facilita en soporte CD-ROM anexo al presente estudio. Dispone de cdigo
comentado para una mejor comprensin de su flujo y manejo de los servicios y
funciones que utiliza.



BIBLIOGRAFA

1. A. CANO, L. VIRGS, J.M. OLIVARES, F. J. QUINTANA, F. GARCA CEPEDA - Ttulo: gvSIG
UN CLIENTE PARA EL SERVICIO WFS DE LA DIRECCIN GENERAL DEL CATASTRO [III
JORNADAS gVSIG (2007)]
2. A. MARQUS MATEU, J.L. BERN VALERO, J.M.GISBERT BLANQUER - Ttulo:
TRANSFORMACIN DE DATUM EN EL CONTEXTO DE UN SIG [EL ACCESO A LA
PUBLICACIN ESPACIAL Y NUEVAS TECNOLOGAS GEOGRFICAS - UNIVERSIDAD
POLITCNICA DE VALENCIA]
3. ALEJANDRA BARRANCO ARENAS, FRANCO SANTOS DOMNGUEZ, VLADIMIR IVN
XOXOCOTLA JIMENEZ - Ttulo: CUADRO COMPARATIVO DE ODBMS [UNIVERSIDAD
TECNOLGICA IZUCAR DE MATAMOROS]
4. ALICIA GONZLEZ, JOS MIGUEL RUBIO, ANA VELASCO, JULIAN GONZLEZ - Ttulo:
ESPECIFICACIONES DEL PRODUCTO CARTOCIUDAD [INSTITUTO GEOGRFICO
NACIONAL DE ESPAA (2011)]
5. ALICIA GONZLEZ, JOS MIGUEL RUBIO, ANA VELASCO, JULIAN GONZLEZ, PATRICIA
TRIGO, PALOMA VERDEJO, GLORIA ANDRS - Ttulo: SERVICIOS WEB DE
CARTOCIUDAD[INSTITUTO GEOGRFICO NACIONAL DE ESPAA (2012)]
6. AMALIA VELASCO MARTN-VARS - Ttulo: LA IMPORTANCIA DE LLAMARSE PARCELA
CATASTRAL [REVISTA CATASTRO (2009)]
7. ANA CERDEIRA-PENA, MIGUEL R. LUACES, SCAR PEDREIRA, DIEGO SECO - Ttulo: UN
SERVICIO DE RESOLUCIN DE TOPNIMOS SIGUIENDO EL ESTNDAR OGS WPS
[INVESTIGACIN DEL LABORATORIO DE BBDD - UNIVERSIDAD DA CORUA]
8. ANA MARA VZQUEZ HOYS - Ttulo: LA IMPORTANCIA DEL AGUA EN LAS
CIVILIZACIONES ANTIGUAS: GRECIA [REVISTA TECNOLOGA DEL AGUA. N 276.
(2006)]
9. ANA VELASCO TIRADO - Ttulo: CARTOCIUDAD. PRIMEROS PASOS AL CUMPLIMIENTO
DE INSPIRE [JJIDE (2012)]
10. ANDRS VALENTN - Ttulo: POR UN SISTEMA INTEGRADO DE DIRECCIONES POSTALES
[COMISIN DE COORDINACIN DEL SITNA]
11. ANTONIO RODRGUEZ AGEA, JOS MIGUEL GONZLEZ AGUILERA - Ttulo: TIC EN EL
AYUNTAMIENTO DE MADRID [REVISTA DE ASTIC (2008)]
12. ANTONIO ROMERO DE LA LLANA - Ttulo: EL MUNDO DE LOS CALLEJEROS, EN
APARIENCIA SENCILLO, ES ALTAMENTE COMPLEJO [DATA CENTRIC (2012)]
13. ANTONIO RUBIO AYUSO, INMACULADA HERNEZ RIOJA - Ttulo: LIBRO BLANCO
TECNOLOGAS DEL HABLA [UNIVERSIDAD DE GRANADA (2005)]
14. AYUNTAMIENTO DE CHAMARTN DE LA ROSA - Ttulo: CATLOGO DE LOS LIBROS DE
LA BIBLIOTECA MUNICIPAL [IMPRENTA Y LITOGRAFA MUNICIPAL (1877)]
15. AYUNTAMIENTO DE MADRID - Ttulo: DIMENSIONES METROPOLITANAS DE LA
CIUDAD DE MADRID [MONOGRFICO DEL BARMETRO DE ECONOMA DE LA CIUDAD
DE MADRID (2007)]


16. AYUNTAMIENTO DE MADRID - Ttulo: GUIA DE ESTNDARES [INFORMTICA
AYUNTAMIENTO DE MADRID (2012)]
17. AYUNTAMIENTO DE MADRID - Ttulo: NORMAS SOBRE DENOMINACIN Y CAMBIOS
DE NOMBRE DE VAS Y ESPACIOS PBLICOS URBANOS [BO. AYUNTAMIENTO DE
MADRID num. 4402 pag. 571-573 (1981)]
18. AYUNTAMIENTO DE MADRID - Ttulo: SERVICIOS CARTOGRFICOS Y DE CALLEJERO
[REA DE GOBIERNO DE URBANISMO Y VIVIENDA. MEMORIA DE GESTIN (2008)]
19. BIBIANA ALEXANDRA LARA TABARES, ANA MARA RODRGUEZ ARVALO - Ttulo:
GUA METODOLGICA PARA LA GENERACIN DE SERVICIOS EN LNEA A PARTIR DE
LOS ESTNDARES WFS Y WMS BASADOS EN VISUALIZACIN CON TRFICO LIVIANO Y
MANEJO DE SEGURIDAD [UNIVERSIDAD JAVERIANA PONTIFICIA (BOGOT) (2004)]
20. BORJA CARBALLO BARRAL - Ttulo: EL ENSANCHE ESTE (1860-1878) [TESIS
DEPARTAMENTO HISTORIA CONTEMPORNEA (UNIVERSIDAD COMPLUTENSE DE
MADRID)]
21. CARLOS SAMBRICIO - Ttulo: UNA PROPUESTA URBANA PARA LA CALLE MAYOR
[PUBLICACIN EN REVISTA TCNICA DESCONOCIDA (Pginas 29 al 38)]
22. CARMEN MANSO PORTO - Ttulo: CATLOGO DE ATLAS, MAPAS SUELTOS y GUAS DE
FORASTEROS [TERCERA PARTE CARTOGRAFA DEL SIGLO XVIII. REAL ACADEMIA DE LA
HISTORIA]
23. CARMEN MUOZ-CRUZADO GARCA - Ttulo: INTRODUCCION A LOS
NOMENCLTORES [CURSO GEOSERVICIOS DEL OGC (2006)]
24. CLAUDIO L. R. STURLA - Ttulo: CADENAS DE MARKOV [APUNTES (2008)]
25. COMISIN CIUDADES DIGITALES - Ttulo: MANUAL DE CIUDADES DIGITALES [AUTELSI
(2009)]
26. CRISTBAL MARN TOVAR - Ttulo: LA CIUDAD HISPANO-MUSULMANA Y EL LEGADO
MADRILEO [CES FELIPE II (ARANJUEZ) (2005)]
27. DANIEL HERNNDEZ LPEZ - Ttulo: MEJORAS EN EL MODELADO ACSTICO PARA
RECONOCIMIENTO DE LOCUTOR DEPENDIENTE DE TEXTO [UNIVERSIDAD AUTNOMA
DE MADRID]
28. DAVID HERST, WILLIAM EDWARDS, STEVE WILKES - Ttulo: COMPARING MICROSOFT
NET AND IBM WEBSPHERE/J2EE [RESEARCH REPORT OF THE MIDDLEWARE
COMPANY (2004)]
29. DIEGO ALBERTO ARIAS PRADO, MANUEL PREZ GMEZ, FRANCISCO VELAYOS
PARDO, RAFAEL CRECENTE MASEDA - Ttulo: SERVICIO DE NOMENCLTOR
UTILIZANDO MOTORES DE BSQUEDA [JIIDE 2012 (Conferencia)]
30. DIEGO H. MILONE - Ttulo: INFORMACIN ACENTUAL PARA EL RECONOCIMIENTO
AUTOMTICO DEL HABLA [TESIS DOCTORAL - UNIVERSIDAD DE GRANADA (2003)]
31. ED KATIBAH, MILAN STOJIC - Ttulo: NEW SPATIAL FEATURES IN SQL SERVER CODE-
NAMED "DENALI" [MICROSOFT. SQL Server Technical Article (2011)]
32. ELISA ISABEL CABALLERO RUZ, FRANCISCO JOS GARCA GONZLEZ - Ttulo: ADYN
HERRAMIENTA DE NORMALIZACIN [JECAS XVII (2010)]
33. ENRIQUE DE DIOS SAN ROMN - Ttulo: AMPLIACIN DE DATOS
GEORREFERENCIADOS EN UN SIG [REVISTA MAPPING]
34. ENRIQUE DE DIOS SAN ROMN - Ttulo: CONTROL Y GENERACIN TOPOLGICA EN
APLICACIONES GIS [REVISTA MAPPING]
35. ENRIQUE DE DIOS SAN ROMN - Ttulo: EL PROGRAMA PROCEDE. EL NUEVO
CATASTRO DE LOS EEUU MEXICANOS [TOPOGRAFA Y CARTOGRAFA. N 63 (1994) ]
36. ENRIQUE DE DIOS SAN ROMN - Ttulo: MANUAL SOFTWARE CATASTRAL PARA


INSTITUTO NACIONAL DE GEOGRAFA Y ESTADSTICA DE MXICO [CARL ZEISS
GERMANY & CARL ZEISS GEO (1995)]
37. ENRIQUE DE DIOS SAN ROMN - Ttulo: MANUAL SOFTWARE DE COLECTOR
TOPOGRFICO DATA V50 [GEO CENTER (1999)]
38. ENRIQUE DE DIOS SAN ROMN - Ttulo: MANUAL SOFTWARE DE OBRA CIVIL ZEITOP
[CARL ZEISS GEO (1994)]
39. ERHARD RAHM, HONG HAI DO - Ttulo: DATA CLEANING: PROBLEMS AND CURRENT
APPROACHES [UNIVERSITY OF LEIPZIG, GERMANY]
40. ESRI - Ttulo: TUTORIAL DE PUBLICACIN DE SERVICIOS WFS [ESRI (2012)]
41. ESRI - Ttulo: TUTORIAL DE PUBLICACIN DE SERVICIOS WFS-T [ESRI (2012)]
42. FERNANDO FERNNDEZ MARTNEZ - Ttulo: ANLISIS, DISEO Y APLICACIN DE
MODELOS DE DILOGO FLEXIBLES, CONTEXTUALES Y DINMICOS BASADOS EN REDES
BAYESIANAS [TESIS DOCTORAL - UNIVERSIDAD POLITCNICA DE MADRID (2008)]
43. FERNANDO SNCHEZ-COSTA - Ttulo: LOS MAPAS DE LA MEMORIA. NOMBRES DE
CALLES Y POLTICAS DE MEMORIA EN BARCELONA Y MADRID [REVISTA HISPANIA
NOVA N 9 (2009)]
44. FRANCISCO JOS MARN PERELLN - Ttulo: LA PUERTA DEL SOL A LO LARGO DE
CUATRO SIGLOS [ILUSTRACIN DE MADRID. N 16. (2010)]
45. FRANCISCO JOS MARN PERELLN - Ttulo: PLANIMETRA GENERAL DE MADRID Y
VISITA GENERAL DE CASAS 1750-1751 [REVISTA CATASTRO (2000)]
46. GENOVEVA TORRES CABRERA - Ttulo: SOBRE TOPONOMSTICA [UNIVERSIDAD DE
LAS PALMAS DE GRAN CANARIA]
47. H. KIEPERT, CH. HUELSEN - Ttulo: FORMAE URVIS ROMAE ANTIQUAE [LIBRERA DE
THE INSTITUTE OF MEDIEVAL STUDIES OF TORONTO (1923)]
48. HEIKKI HYYR - Ttulo: A BIT-VECTOR ALGORITHM FOR COMPUTING LEVENSHTEIN
AND DAMERAU EDIT DISTANCES [UNIVERSITY OF TAMPERE - FINLAND]
49. HERMENEGILDO GARCA-AREZ - Ttulo: LOS MAPAS MUNDIS DE LOS BEATOS
[MISCELNEA MEDIEVAL MURCIANA. Vol XIX-XX. (1996)]
50. I.N.E. - Ttulo: LOS CENSOS DE POBLACION EN ESPAA [INSTITUO NACIONAL DE
ESTADSTICA (2011)]
51. IBM - Ttulo: OPC AUTOMATION PROGRAMMERS REFERENCE AND OPERATORS
GUIDE [IBM (2004)]
52. IGNACIO DUQUE, NGEL SNCHEZ - Ttulo: TOMO 5. HOGARES, FAMILIAS Y NCLEOS.
CARACTERSTICAS DEMOGRFICAS BSICA [CONSEJERIA DE ECONOMIA (ESTADSTICA
- COMUNIDAD DE MADRID) 1991]
53. INSPIRE THEMATIC WORKING GROUP ADDRESSES - Ttulo: INSPIRE DATA
SPECIFICATION FOR THE SPATIAL DATA THEME ADDRESSES [INFRASTRUCTURE FOR
SPATIAL INFORMATION IN EUROPE (UE) (2010)]
54. INSTITUTO GEOGRFICO NACIONAL DE ESPAA - Ttulo: NOMENCLTOR
GEOGRFICO CONCISO DE ESPAA [INSTITUTO GEOGRFICO NACIONAL DE ESPAA
(2006)]
55. ISABEL OTERO PASTOR - Ttulo: TOPOMETRA [OPEN CURSE WARE (OCW) DE LA
UNIVERSIDAD POLITCNICA DE MADRID]
56. J. M JIMENO JURO - Ttulo: BORRADOR DE LA GUA PARA LA RECOGIDA
TOPONMICA DEL PAS VASCO [EUSKERA - XXXII (2.aldia) Pginas 429-442]
57. J.M. LAVAREZ, O. COTORRUELO, M. ELORZA, J.L. TEBERIO, J. ZURUTUZA - Ttulo:
CAMBIO DE DATUM A ETRS89 DE LA BASE TOPOGRFICA 1:5000 EN EL TERRITORIO
HISTRICO DE GUIPZCOA [DEPARTAMENTO DE MOVILIDAD Y ORDENACIN DEL


TERRITORIO DE LA DIPUTACIN FORAL DE GUIPZCOA]
58. J.M. LUCAS, F. FERNNDEZ , J. SALAZAR, J. FERREIROS, R. SAN SEGUNDO - Ttulo:
MANAGING SPEAKER IDENTITY AND USER PROFILES IN A SPOKEN DIALOGUE SYSTEM
[PROCESAMIENTO DEL LENGUAJE NATURAL, N 43 (2009)]
59. JAVIER DELGADO BERMEJO - Ttulo: LOS SISTEMAS DE INFORMACIN GEOGRFICA
DE GESTIN EN EL AYUNTAMIENTO DE MADRID [REVISTA DE ASTIC (2009)]
60. JAVIER GONZLEZ MATESANZ, DAVID HERNNDEZ LPEZ, LUIS W. SEVILLA - Ttulo:
jCRS: EXTENSIN DE gvSIG PARA LA GESTIN DE SISTEMAS DE REFERENCIA DE
COORDENADAS [I JORNADAS DE SIG LIBRE (2007)]
61. JAVIER GONZLEZ-MATESANZ, ADOLFO DALDA, RAFAEL QUIRS, JESS CELADA -
Ttulo: ED50-ETRS89 TRANSITION MODELS FOR THE SPANISH GEODETIC NETWORK
[INSTITUTO GEOGRFICO NACIONAL DE ESPAA]
62. JAVIER MARTNEZ JIMNEZ - Ttulo: EL USO Y EL SUMINISTRO DE AGUA A LA CIUDAD
DE ROMA EN EL PERIODO OSTROGODO [REVISTA ESPACIOS URBANOS EN EL
OCCIDENTE MEDITERRNEO (S . VI-VIII) / 267-274]
63. JAVIER MARTINEZ VALDUEZA, JAVIER DELGADO BERMEJO - Ttulo: EL PADRN
MUNICIPAL DE HABITANTES EN EL AYUNTAMIENTO DE MADRID [REVISTA DE ASTIC
(2009)]
64. JAVIER SNCHEZ ESPESO - Ttulo: GEODESIA ESPACIAL PARA INGENIEROS
[UNIVERSIDAD DE CANTABRIA (2009)]
65. JESS VELASCO - Ttulo: PROPUESTA METODOLOGA DE DISEO, OBSERVACIN Y
CLCULO DE REDES TOPOGRFICAS PARA LA CONSTRUCCIN DE TNELES DE GRAN
LONGITUD PARA FERROCARRILES DE ALTA VELOCIDAD [TESIS DOCTORAL
UNIVERSIDAD POLITCNICA DE MADRID (2010)]
66. JOAQUN CARIDAD ARIAS - Ttulo: LOS FENMENOS DE HOMONIMIA Y HOMOFONA
EN LA TOPONOMSTICA Y SU REPERCUSIN EN LAS ETIMOLOGAS CULTISTAS Y
POPULARES DE LA EUROPA OCCIDENTAL [TESIS DOCTORAL (UNIVERSIDAD DE LA
LAGUNA) (2004)]
67. JOEL GRAU BELLET - Ttulo: TRANSFORMACI BIDIMENSIONAL DE SEMBLANA ENTRE
ED50 I ETRS89[INSTITUTO CARTOGRFICO DE CATALUA (COMUNIDAD AUTNOMA
DE CATALUA) (2010)]
68. JOSE ANTONIO ANTA - Ttulo: DESARROLLO DE APLICACIONES MVILES [ESRI -
CONFERENCIA USUARIOS (2010)]
69. JOS ANTONIO SNCHEZ SOBRINO - Ttulo: INTRODUCCIN A LA GEODESIA [X CURSO
DE GPS EN GEODESIA Y CARTOGRAFIA - MONTEVIDEO (2010)]
70. JOS LUIS PINAR GMEZ - Ttulo: IDENTIFICACIN DE AUTORES EN BBDD
BIBLIOGRFICAS [CONSEJO SUPERIOR INVESTIGACIONES CIENTFICAS - UNIVERSIDAD
POLITCNICA DE VALENCIA (2007)]
71. JOS MANUEL MORENO MARTINEZ - Ttulo: USOS DE CADENAS DE MARKOV PARA LA
PREDICCIN DE LA APARICIN DE UNA IDE EN UN PAS EN VAS DE DESARROLLO
[UNIVERSIDAD DE SEVILLA (2011) TRABAJO FIN DE MASTER EN DESARROLLO Y
GESTIN TERRITORIAL Y LOCAL]
72. JOS SIMN DAZ - Ttulo: NOMENCLTOR LITERARIO DE LAS VAS PBLICAS DE
MADRID [(Pginas 401 a 451)]
73. JOSEFINA SEZ BURGAYA - Ttulo: BALANCE DE LA IDEBARCELONA Y DESARROLLO DE
LAS IDEE LOCALES[DIPUTACIN DE BARCELONA]
74. JOSEG ADAM, WOLFGANG AUGATH, CLAUDE BOUCHES, CARINE BRUYNINX, PAUL
DUNLEY, ERICH GUBLER, WERNER GURTNER, HELMUT HORNIK, HANS V.D. MAREL,


WOLFGANG SCHLTER, HERMANN SEEGER, MARTIN VERMEER, JANUSZ B.ZIELINSKI -
Ttulo: THE EUROPEAN REFERENCE SYSTEM COMING OF AGE [EUREF
SUBCOMMISSION SECRETARY (2000)]
75. JUAN RAMN MESA DAZ - Ttulo: ESTUDIO COMPARATIVO ENTRE SIG PROPIETARIO
Y SIG LIBRE [II JORNADAS SIG LIBRE (2008)]
76. LAWRENCE RICHARDSON - Ttulo: A NEW TOPOGRAPHICAL DICTIONARY OF ANCIENT
ROME [THE JOHNS HOPKINS UNIVERSITY PRESS (1992)]
77. LUIS ARIJN LVAREZ - Ttulo: SISTEMA DE INFORMACIN CATASTRAL EN ESPAA
[XII SEMINARIO DE CATASTRO INMOBILIARIO (BOLIVIA) (2009)]
78. LUIS DE ELEIZALDE - Ttulo: LISTAS ALFABTICAS DE VOCES TOPONOMSTICAS
VASCAS [SOCIEDAD DE ESTUDIOS VASCOS EUSKO-IKASKUNTZA (1916)]
79. LUIS MIGUEL APARISI LAPORTA - Ttulo: TOPONIMIA FRANQUISTA EN LAS CALLES DE
MADRID [AYUNTAMIENTO DE MADRID (2001)]
80. M. DAVIS, J. AQUINO - Ttulo: JTS TOPOLOGY SUITE. TECHNICAL SPECIFICATIONS
[VIVID SOLUTIONS (2004)]
81. M. FARJAS - Ttulo: REDES TOPOGRFICAS [BOLETN INFORMATIVO DEL IGN, N 3
(2000)]
82. M SANDRA GARCA PREZ - Ttulo: EL PADRN MUNICIPAL DE HABITANTES: ORIGEN,
EVOLUCIN Y SIGNIFICADO [REVISTA HISPANIA NOVA N 7 (2007)]
83. MARGARITA AZCRATE LUXN, ADELA ALCZAR GONZLEZ, XERMN GARCA MIKEL,
GORROTXATEGI NIETO, AIGES VIVES PREZ I PIQUER - Ttulo: DIRECTRICES
TOPONMICAS DE USO INTERNACIONAL PARA EDITORES DE MAPAS Y OTRAS
PUBLICACIONES [CNIG (INSTITUTO GEOGRFICO NACIONAL DE ESPAA - 2011)]
84. MARA JOS MUOZ DE PABLO - Ttulo: LAS TRAZAS DEL AGUA AL NORTE DE LA VILLA
DE MADRID [REVISTA AIEM, XLVI, 2006]
85. MARIANO RIVERA, OMAR OCEGUEDA, JOS LUIS MARROQUN - Ttulo: HIDDEN
GAUSS-MARKOV RANDOM MEASURE FIELD MODELS FOR EFFICIENT IMAGE
SEGMENTATION [PUBLICACIN EN REVISTA TCNICA DESCONOCIDA]
86. MARKO OLLIKAINEN, MATTI OLLIKAINEN - Ttulo: THE FINNISH COORDINATE
REFERENCE SYSTEMS [FINNISH GEODETIC INSTITUTE Y NATIONAL LAND SURVEY OF
FINLAND]
87. MAZEN SULEIMAN SHINAQ - Ttulo: LA CIUDAD MUSULMANA Y LA INFLUENCIA DEL
URBANISMO OCCIDENTAL EN SU CONFORMACIN [CUADERNOS DE INVESTIGACIN
URBANSTICA, N 33 (2009)]
88. MIGUEL RODRGUEZ LUACES - Ttulo: INFORMACIN GEOGRFICA BD ESPACIALES y
BD ESPACIO-TEMPORALES [II JORNADAS SIG LIBRE (2008)]
89. MINISTERIO DE FOMENTO - Ttulo: LA PLANIMETRA DE MADRID EN EL SIGLO XIX
[PUBLICACIN MINISTERIO DE FOMENTO (2011)]
90. MIQUEL PARELLA - Ttulo: ESPECIFICAIONES DE DATOS PARA NOMBRES
GEOGRFICOS DE INSPIRE [INSTITUTO CARTOGRFICO DE CATALUA(COMUNIDAD
AUTNOMA DE CATALUA)]
91. MOISS GIL SOLDEVILLA - Ttulo: INTERFAZ EN LENGUAJE NATURAL A TRAVS DE WEB
PARA EL ACCESO A LOS SERVICIOS DE BSQUEDA DE UN CATLOGO DE
INFORMACIN GEOGRFICA ACORDE CON EL ESTNDAR OPENGIS [UNIVERSIDAD DE
ZARAGOZA (2002)]
92. MOISS PASTOR I GADEA - Ttulo: APORTACIONES AL RECONOCIMIENTO
AUTOMTICO DE TEXTO MANUSCRITO [TESIS DOCTORAL UNIVERSIDAD POLITCNICA
DE VALENCIA]


93. MNICA ESCRIBANO ROMERO - Ttulo: BSQUEDAS EN REDES JERRQUICAS
[UNIVERSIDAD JUAN CARLOS III (2010)]
94. ORDNANCE SURVEY - Ttulo: A GUIDE TO COORDINATE SYSTEMS IN GREAT BRITAIN
[GUIDES OF THE NATIONAL MAPPING AGENCY OF GREAT BRITAIN]
95. OSCAR MARIO RODRGUEZ SNCHEZ - Ttulo: LAS MATEMTICAS EN EL
RENACIMIENTO [APUNTES DE HISTORIA DE LAS MATEMTICAS. VOL. 1, NO. 3,
SEPTIEMBRE 2002]
96. PALOMA ABAD POWER, ANTONIO RODRIGUEZ PASCUAL, EMILIO LPEZ ROMERO,
ALEJANDRA SNCHEZ MAGANTO - Ttulo: APLICABILIDAD DEL MODELO DE
NOMENCLTOR DE ESPAA AL NOMENCLTOR CONCISO [INSTITUTO GEOGRFICO
NACIONAL DE ESPAA]
97. PALOMA MARTNEZ FERNNDEZ - Ttulo: PROPUESTA DE ESTRUCTURACIN DEL
CONOCIMIENTO LINGISTICO PARA INTERPRETACIN DE TEXTOS [TESIS DOCTORAL
UNIVERSIDAD POLITCNICA DE MADRID (1998)]
98. PAPA CALIXTO II - Ttulo: LIBER PEREGRINATIONIS O CDEX CALIXTINUS [LIBRO V (S.
XII)]
99. PAUL C. SMITS, PAOLO GAMBA - Ttulo: FUSIN DE DATOS GEOESPACIALES. REVISIN
Y ESTADO ACTUAL [GRSS - IEEE GEOSCIENCE & REMOTE SENSING SOCIETY]
100. PAUL JANSEN - Ttulo: THE TIOBE QUALITY INDICATOR. A PRAGMATIC WAY OF
MEASURING CODE QUALITY[TIOBE SOFTWARE 2012]
101. PAULO MARTNEZ LEMA - Ttulo: APROXIMACIN LINGISTICO-ETIMOLXICA
TOPONIMIA DAS COMARCASDE XALLAS, FISTERRA E SONEIRA [REVISTA DE FILOLOGA
ROMNICA vol. 27 237-262 (2010)]
102. PEDRO NAVASCUES PALACIO - Ttulo: MADRID, CIUDAD Y ARQUITECTURA (1808-
1898) [(Pginas 401 a 439)]
103. R. QUIRS, M. A. CANO, J. A. S. SOBRINO, M. VALDS - Ttulo: SPANISH NATIONAL
GPS REFERENCE STATIONS NETWORK (ERGPS) [INSTITUTO GEOGRFICO NACIONAL
DE ESPAA]
104. RAL ALBA, ISAAC MORENO GALLO - Ttulo: ELEMENTOS DE INGENIERA ROMANA
[CONGRESO EUROPEO DE OBRAS PBLICAS ROMANAS (2004)]
105. ROB ATKINSON, JENS FITZKE - Ttulo: GAZETTEER SERVICE PROFILE OF THE WEB
FEATURE SERVICE IMPLEMENTATION SPECIFICATION [OPEN GIS CONSORTIUM INC
(2002)]
106. SANTIAGO JIMNEZ SERRANO - Ttulo: OPTIMIZACIN DE RUTAS DE VUELO PARA UN
HIDROAVIN EN SUS TAREAS DE VIGILANCIA DE INCENDIOS FORESTALES
[UNIVERSIDAD POLITCNICA DE VALENCIA (2011)]
107. SPANISH COMMITTEE OF GEODESY AND GEOPHYSICS - INSTITUTO GEOGRFICO
NACIONAL - Ttulo: NATIONAL REPORT ON GEODESY 2003-2006 [IUGG XXIV GENERAL
ASSEMBLY]
108. TOMS FERNNDEZ - Ttulo: ASIGNATURA CARTOGRAFA I DE I.T. TOPOGRAFIA
[UNIVERSIDAD DE JAN (2008)]
109. UNIDAD DE GEODESIA Y UNIDAD WEB-SIG - Ttulo: INCORPORACI DE LES MALLES
NTV2 EN EL PROGRAMARI ARCGIS SERVER [INSTITUTO CARTOGRFICO DE CATALUA
(COMUNIDAD AUTNOMA DE CATALUA) (2012)]
110. XAVIER BONET PORTA - Ttulo: CREACIN DE LIBRERAS PARA LA ASIGNATURA DE
NAVEGACIN AREA, CARTOGRAFA Y COSMOGRAFA [UNIVERSIDAD POLITCNICA
DE CATALUA (2008)]



WEB INTERESANTES

1. ACADEMIA VALENCIANA DE LA LENGUA [ www.avl.gva.es/ ]
2. AFRITERRA FUNDATION [ http://www.afriterra.org/ ]
3. ALPOMA [ http://alpoma.net/carto/ ]
4. APUNTES DE ARQUITECTURA [ http://apuntesdearquitecturadigital.blogspot.com.es/ ]
5. ARTE EN MADRID [ http://artedemadrid.wordpress.com/ ]
6. AYUNTAMIENTO DE MADRID [ http://www.madrid.es ]
7. BIBLIOTECA CERVANTES [ http://www.cervantesvirtual.com/ ]
8. C# RECURSOS MICROSOFT [ http://msdn.microsoft.com/es-es/vstudio/hh341490.aspx ]
9. CALLEPAA [ http://callespana-demos.com.es/ ]
10. COMUNIDAD DE MADRID. BIBLIOTECA [ http://www.bibliotecavirtualmadrid.org/ ]
11. CONSULTA CALLEJERO DE MADRID [ http://www-
2.munimadrid.es/ConsultasBDCWebSqlInternet/jsp/index.jsp ]
12. CURSO DE WPF [ http://es.scribd.com/doc/77281155/Bienvenido-Al-Curso-de-Wpf ]
13. DEEGREE [ http://www.deegree.org/ ]
14. GEOSERVER [ http://geoserver.org/ ]
15. GEOTOOLS [ http://www.geotools.org/ ]
16. HEMEROTECA PERIDICO ABC [ http://hemeroteca.abc.es/ ]
17. HISPANIA NOVA [ http://hispanianova.rediris.es/ ]
18. HISTORIA ARQUITECTURA DE ESPAA [
http://www.spanisharts.com/arquitectura/inicio.html ]
19. IDEE DE ESPAA [ http://www.idee.es/ ]
20. INSTITUTO CARTOGRFICO DE CATALUA [ http://www.icc.cat/esl ]
21. INSTITUTO GEOGRFICO NACIONAL [ http://ign.es/ ]
22. INSTITUTO NACIONAL DE ESTADSTICA [ http://www.ine.es/ ]
23. JAVA [ www.java.com/es/download/ ]
24. JOSE MANUEL CASTELLANOS OATE [ http://elmadridmedieval.jmcastellanos.com/ ]
25. MADRID HISTRICO [ http://madridhistorico.com/ ]
26. MADRIPEDIA [ http://madripedia.es/ ]
27. MAPSERVER [ http://mapserver.org/ ]
28. MINISTERIO DEL INTERIOR [ http://www.interior.gob.es/ ]
29. MONOGRAFAS [ http://www.monografias.com ]
30. NLP SERVICES [ http://nlpdotnet.com/ ]
31. NOMENCLATOR COMUNIDAD DE MADRID [ http://www.madrid.org/nomecalles/ ]
32. NOTARIOS Y REGISTRADORES [ http://www.notariosyregistradores.com/ ]
33. OPEN GEOSPATIAL CONSORTIUM [ http://www.opengeospatial.org/ ]


34. ORACLE [ www.oracle.com/es/ ]
35. POSTGIS [ http://postgis.refractions.net/ ]
36. REAL ACADEMIA DE LA HISTORIA [ http://www.rah.es/ ]
37. REAL ACADEMIA DE LA LENGUA ESPAOLA [ www.rae.es/ ]
38. REAL ACADEMIA DE LA LENGUA GALLEGA [ http://www.realacademiagalega.org/ ]
39. REAL ACADEMIA DE LA LENGUA VASCA [ http://www.euskaltzaindia.net/ ]
40. REVISTA CATALANA DE GEOGRAFA [ http://www.rcg.cat/ ]
41. REVISTA DE ARTE [ http://www.revistadearte.com/ ]
42. REVISTA NDICE [ http://www.revistaindice.com/ ]
43. SEXTANTE [ http://www.sextantegis.com/ ]
44. SQLLITE [ http://www.sqlite.org/ ]
45. SQLSERVER [ www.microsoft.com/sqlserver/ ]
46. WIKIPEDIA [ http://es.wikipedia.org/ ]

Diseño de Un Modelo de Nomenclátor Centralizado en El Ámbito de Las Administraciones Locales de Gran Tamaño - Enrique de Dios San Román PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diseño de Un Modelo de Nomenclátor Centralizado en El Ámbito de Las Administraciones Locales de Gran Tamaño - Enrique de Dios San Román PDF

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE SALAMANCA

ESCUELA POLITCNICA SUPERIOR DE VILA

You might also like