Smart cities: what about the reuse?

Posted on 29/03/2016 by mjlobato76

imagen proyectosAt this point in our live we still get indignant about seeing tenders and public grants and most of them related to Smart Cities in the last years where basically citizens money is spent in software licenses acquisition. Licenses with names and surnames in a high percentage of cases.

At the series of posts that we started about Smart Cities and open source software we dealt with the reasons why a city only can be intelligent if it guarantees the technological independence of its information systems and why the proprietary software deepens in the technological discrimination between first and second class cities.

Today, we would like to focus on a subject that however, being in all the basic manuals of the government, it seems that when it concerns to the software area, many times is forgotten and relegated to something insignificant. wet paper. As much as this area has a legislative character.

And if, the topic is the reuse. Subject that tells us that our public managers must focus on solutions to be shared, reused, that they can be improved and supplemented between administrations. In computing solutions this is only possible with open source software licenses.

In one previous post, we talked about that for the vast majority of cities the only option to get into the modernization of the public management was the open source software, now we should think about the savings and the technological advance which will be created if the solutions were shared. If it would be a collaboration in the evolution, if the efforts would be added…

The needs of the cities are, basically, the same ones in any part of the world. Infrastructure management (sewage and water management, lighting,…), heritage, town inventory, waste management, town planning,…the software solutions, therefore, could have one similar technological base. And if all the data are geolocated, the geomatics, the GIS are a fundamental key in the Smart Cities framework. We talk from the practice and the experience of the gvSIG Association, knowing that the 100% of all the geomatics needs of any town can be solved with total guarantee for the open source software..

And with the weight of the logic of reusing, the actual legislation must be added, which is equivalent in all countries. Let´s see the case of Spain.

The (ENI), governed by Royal Decree 4 / 2010 of 8 January, establishes the set of criteria and recommendations which should be taken into account by supplied by public administrations for decision-making to guarantee interoperability. ENI is aligned with the European Strategy for interoperability and Interoperability European Framework. Both the ENI, and their interoperability technical standards, provide for systematic liaison with equivalent instruments the European area.

And what says about reusing? The article 16 says:

The licensing conditions of the applications and associated documentation, and any other information objects which public authorities are holders of intellectual property rights and that they can make available to other public administrations and citizens, without nothing in return or any agreement, they will take into account that the aim pursued is the use and reuse, as well as the protection against any misappropriation exclusively by third parties .

Indicates that the Administrations should take into account the available solutions for free reuse, that can satisfy (all or part) of the needs of the new systems and services or improving and updating those already implemented.

And concludes that: the main aim of the release of assets is the possible Reuse of the same ones by other stakeholders. Organizations, particularly, public governments, dedicate efforts to create assets that may already exist . The reuse of these assets can allow the sharing of resources and results , on the one hand, within government and including contributing to save resources, effort and time , and, on the other hand, society, contributing to social and economic interest.

Great laws, aren´t they? And now, are we going to take them seriously? To bet for the reusing is to bet for the free technologies. Technological sovereignty, reduction of asymmetries and reuse.

We must ask for smart managers to have smart cities.

Posted in english, opinion | Tagged , , | 2 Comments

Smart Cities: Can only the big cities be intelligent?

Posted on 22/03/2016 by Mario

livingcities_peq

Some days ago we talked about that it’s not possible to apply the Smart City concept, the intelligent city concept, to that cities where their public managers apply policies and projects that make their technological infrastructures, their information systems, are dependent on sole providers. Unfortunately it happens frequently and it jeopardizes the technological future of the cities.

Stressing in that issue about the Smart Cities there’s another aspect that we would like to stand out related to the proprietary software opposite to open source solutions. That’s the direct relationship between the proprietary products implementation and the generation of technological inequality between towns in a different economical level.

Everybody consider that license expenses for implementing and maintaining a geomatics platform that allows to manage geographic information is only accessible for a few city councils. A minimum percentage of the total of municipalities of any country.

Using proprietary software we are pushing most of the towns of a country into the background. This discrimination of the modernization of the city councils management causes that there’s only a few modernity examples, enough to fill in some newspaper headlines. It also causes that we condemn the rest to a digital exclusion. It doesn’t seem to be the “most smart” and more intelligent policies.

If the digital opening is mainly referring to the possibilities to convert the circulating information into relevant knowledge, betting on free solutions, based on shared knowledge, without license expenses and access limitations, is the only possibility for all the cities and towns in a country to apply the technology in order to improve their management.

And everything without entering in the own dynamics of the open source software, where the possibilities to collaborate between different municipalities are open to deal with joint developments that can be shared without any limitations.

And an intelligent country won’t be these one that has first and second class cities, intelligent and “not as much intelligent”, but the country who bets on an equality in technological opportunities for all the municipalities, and besides allows them to share and improve in a joint way.

Posted in english, opinion | 2 Comments

Running R source code from gvSIG 2.3 through Renjin

Posted on 17/03/2016 by Mario

One of the new features included in gvSIG 2.3, that was commented at the 11th International gvSIG Conference (there’s also a question from an attendee at the end of the video), is the possibility to run R source code from the Scripting module. To run these R scripts, the Renjin library will be used. We’re going to tell about how to do it.

Renjin is an R interpreter made on Java, but it’s not exactly the native R that we know. It allows us to run code on R and work with all the gvSIG API on Java at the same time. This library has several benefits since it’s completely built-up in gvSIG because it supports Java libraries, but it also have some limitations. One of them is that not all the R libraries are available to be used with Renjin.

“Using Rejin, we have a great integration with gvSIG, but less integration with R”

You can find more information about Renjin in their website, as well as the R libraries, that are available to be used. Renjin is actively in development, so that we hope that there are improvements in the future, about compatibility as well as in functionalities.

We are going to show you a pair of examples. We have to open gvSIG and go to Tools – Scripting – Scripting Composer, and here we create a new Script (an R script).

We can try to run some typical R source code like this:

main <- function() {
cat( "Hello\n" );
cat( "Hello\n" );
d1 <- c(1,3,5);

x <- sample(c("A", "B", "C"), size = 10, replace = TRUE)
print(as.factor(x))

df <- data.frame(x = seq(5), y = runif(5))
print(df)
}

that will show this text by console:

Running script rtest_000.
Hello
Hello
[1] B A B B A C B A A C
Levels: A B C
x y
1 1 0,869
2 2 0,85
3 3 0,255
4 4 0,497
5 5 0,549
Script rtest_000 terminated.

At the following example we are going to show how a Java class can be imported:

import(java.util.HashMap)

main <- function() {

"Renjin example with Java"
ageMap <- HashMap$new()
ageMap$put("Bob", 33)
ageMap$put("Carol", 41)
print(ageMap$size())
age <- ageMap$get("Carol")
cat("Carol is ", age, " years old.\n", sep = "")

print(ageMap)

}

that will show:

Running script rtest_001.
[1] 2
Carol is 41 years old.
Script rtest_001 terminated.

And finally, and more interesting, we are going to show how to interact with gvSIG, accessing to one of the Views that is open in our project to show its name, importing the classes that we need:

import (org.gvsig.app.project.documents.view.ViewDocument)
import (org.gvsig.app.ApplicationLocator)

main <- function() {

 cat( "Accessing to a View\n" );
 application <- ApplicationLocator$getManager();

 view <- application$getActiveDocument(ViewDocument);
 print(view$name)

}

It would show this text by console:

Running script rtest_02.
Accessing to a View
[1] "GVSIG VIEW 01"
Script rtest_02 terminated.

 

We still have to find the best way to work with Renjin and gvSIG, since we still are in a development process of this module.

Any collaboration, or feedback that we get from you is welcome.

Posted in development, english, gvSIG Desktop, scripting | Tagged , | 3 Comments

Smart cities: decisiones técnicas, decisiones políticas

Posted on 16/03/2016 by Alvaro

chess

Quiero cerrar la serie de post sobre Smart Cities y de la relación indisoluble entre Smart Cities y software libre con una cuestión que pocas veces se trata y que muchas se ignora. En esto del software, ¿qué debería ser una decisión política y qué debería ser una decisión técnica?.

Antes de seguir, si no has leído los post anteriores, te recomiendo que lo hagas. En ellos se argumentaban los motivos principales por los que una Smart City debe necesariamente tener sus sistemas de información (geográfica y de cualquier tipo) basados en tecnologías libres.

– Porque es la única garantía de independencia tecnológica.

– Porque reduce asimetrías y la brecha digital entre ciudades.

– Porque posibilita la reutilización de soluciones, la suma de esfuerzos.

En la actualidad nos encontramos con que, pese a la lógica de los argumentos y las leyes que los respaldan, en los proyectos relacionados con las Smart Cities se gastan cantidades indignantes de dinero público en la adquisición de licencias. ¿Quién es el responsable último de esto? ¿El técnico o el político? ¿Quién debe definir en los términos de referencia de las licitaciones las condiciones relativas al licenciamiento?

Por mi experiencia la norma es que lo define el departamento técnico. Un grupo de servidores públicos que trabajan en un área técnica definen los requisitos funcionales y, además, acostumbrados y formados en la universidad en el uso de determinadas marcas…indican que los servicios a prestar deben incluir el uso de determinadas licencias de software. Esta situación hace que o el técnico tiene un conocimiento de las perniciosas repercusiones de implantar software privativo en su institución y un sentido de la responsabilidad para evitarlas…o tengamos un nuevo caso de propagación de dependencia tecnológica institucional.

¿Y el político? Pues me atrevería a decir que, tristemente, en el 99% de los casos esto del software, de la tecnología, ni le importa ni le interesa. Es decir: No lo ve importante. En muchos casos existe, además, una falta de comunicación total entre parte política y técnica.

Imaginemos que es necesario realizar una nueva infraestructura, una carretera, una calle, un parque, una escuela, un centro sanitario…elijan la que más les guste.

¿Cuáles serán las decisiones técnicas? El tipo de asfalto, el ancho de la acera, los tipos de árboles, etc. ¿Alguien se puede imaginar que sea un técnico el que decida que la carretera ha de ser pública o ser una autovía, que la calle se dedique al uso público o privado, que la escuela sea pública o privada?…las decisiones sobre las condiciones de uso de cualquier infraestructura de la ciudad son decisiones políticas. ¿Por qué con la infraestructura tecnológica no pasa lo mismo?

Sirvan estas analogías para determinar que el uso de software libre debería ser siempre una decisión política y nunca técnica.

Espero que esta serie de post hayan sido de vuestro interés y sirvan para abrir un debate necesario. Desde la Asociación gvSIG ofrecemos toda nuestra experiencia y conocimiento para apostar por Smart Cities y soluciones libres.

Necesitamos ciudades inteligentes, necesitamos ciudades libres tecnológicamente.

Posted in opinion, spanish | Tagged , | 7 Comments

Script para convertir DXF a GML parcela catastral con gvSIG 2.3 ( Gracias a @SIGdeletras )

Posted on 16/03/2016 by Óscar Martínez

Hace unos días nuestro compañero Patricio Soriano del blog de sigdeletras  realizó un pequeño script de Python que nos ayuda en la conversión de un fichero DXF a uno GML, siguiendo las indicaciones del catastro actual.

Podéis encontrar información sobre estos pasos y enlaces a las fuentes que ha utilizado para documentarse mucho mejor explicado en su post: dxf2gmlcatastro. Script Python para convertir de DXF a GML parcela catastral 
Este script tiene sus limitaciones al ser un primer intento de desarrollo. Podéis leer tus ventajas y sus contras en su repositorio de Github: dxf2gmlcatastro.

Y bueno, vamos al asunto, una cosa importante del script es que para realizar esta transformación utiliza la librería de GDAL de Python. Eso nos obligaría a instalar GDAL en nuestra máquina y hacer que funcione sin romper nada más (por propia experiencia esto no siempre es tan sencillo). Así que vamos a aprovechar el GDAL que viene gvSIG 2.3, que vendrá de serie a partir de esta versión y que en un futuro cercano hasta tendremos versión portable, sirviéndonos de entorno de desarrollo. Será descomprimir, abrir y desarrollar, ¿sencillo verdad?

Para que funcionase este script, solo he tenido que añadir un par de funcionalidades como indicar la carpeta de salida para facilitar su ejecución, y modificar algo el código para adaptarlo al GDAL que se utiliza a través de Java en gvSIG (probablemente estas modificaciones se pudiesen realizar en el código de Python y funcionaria correctamente).

¿Quieres probarlo?

  1. Lo primero sería tener gvSIG 2.3. Ahora mismo estamos en la versión candidata a final. Si no te quieres descargar una versión aún en fase de prueba, no te preocupes, pronto estará la final.
  2. Descarga el script dxf2gmlcatastro-master-for-gvsig (click en View Raw)
  3. Descomprimirlo en esta carpeta /dxf2gmlcatastro-master/ dentro de nuestra carpeta de Scripts en gvSIG.
    En Windows: C:\Users\{}\gvSIG\plugins\org.gvsig.scripting.app.mainplugin\scripts
    En Linux: En el home \gvSIG\plugins\org.gvsig.scripting.app.mainplugin\scripts
  4. Abrimos gvSIG y vamos a Herramientas – Scripting – Scripting Composer. A la izquierda aparecerán nuestros scripts. Abrimos gvsig_dxf2gmlcatastro
  5. Establecemos la ruta del fichero de salida, en este caso he puesto una carpeta que nos sea fácil de acceder (tiene que existir la carpeta para que funcione el script). Se establece en la línea 90: tempgml = r’C:/temp/gmlcatastro001.gml’
  6. Este script ya viene preparado para ejecutar el fichero de ejemplo que se encuentra directamente en la carpeta. Ya lo podríamos ejecutar.
  7. Si quieres utilizar tu fichero DXF que se encuentre en otra ruta, deberás escribir el nombre del fichero en dxffile (línea 83) y el path en el que se enecuentra en path_dxffile (línea 84), por ejemplo:
dxffile = "p.dxf"
path_dxffile = r"C:/temp/"

Ejecutas dando click al boton de la Rueda que se encuentra arriba (lo puedes ver en la imagen siguiente)
2016_03_16_11_98_38-gvsigscriptingcomposerLa salida por consola deberá ser similar a lo que aparece en la imagen. Si tienes algún problema puedes escribirnos en este post o en la lista de desarrollo.

¡Listo! Ya tendrías el fichero gml creado en la carpeta que le indicaste, y gracias a que gvSIG tiene soporte para gml, podríamos cargarlo en nuestra vista.

2016-03-16 11_09_37-gvsigml
Desde gvSIG se podrían hacer rápidamente muchísimas mejoras al poder aprovechar todas las librerías que nos vienen con el programa y nos aportarían usabilidad para el usuario final.
Podríamos fácilmente crear unos cuadros de dialogo que nos permitieran elegir dónde está nuestro fichero o dónde queremos guardarlos (evitando al usuario final que se meta a tocar el código). Se podría crear una interfaz visual en pocos minutos que ya casi transformaría un pequeño script, en todo un plugin utilizable por cualquier usuario. También se podría ejecutar desde un botón en la barra de herramientas.

Tu script que necesitaba instalación de librerías y toqueteo de código, se convierte en muy muy poco tiempo, en un plugin para gvSIG el cual no necesita instalación de ninguna librería, solo la del propio plugin y sin necesidad de tocar código por parte del usuario. Facilitando su uso y que pueda llegar a más gente, que al final es para lo que lo hacemos.

Esperamos que os resulten interesantes estos tipo de post (porque vendrán más).

Un saludo,
Óscar

PD: Todos los agradecimientos posibles a Patricio Soriano por informarse, crear y liberar el código 🙂

PD2: ¡Recordaros hacer copia de seguridad de vuestra carpeta de Scripts de vez en cuando!

Posted in development, gvSIG Desktop, gvSIG development, scripting, spanish | Tagged , | 3 Comments

Ejecutando código de R desde gvSIG 2.3 mediante Renjin

Posted on 15/03/2016 by Óscar Martínez

Una de las novedades introducidas en gvSIG 2.3 y que ya comentamos en las 11as Jornadas Internacionales gvSIG (también hay una pregunta del público al final del vídeo), es la oportunidad de ejecutar código de R desde el Módulo de Scripting. Para realizar la ejecución de estos scripts de R, utilizamos la librería de Renjin. Vamos a explicar un poco más sobre esto.

Renjin es un interprete de R hecho en Java, no es exactamente el R nativo que conocemos. Nos permite ejecutar código en R a la vez que trabajar con toda la API de gvSIG, escrita en Java. Esta librería tiene sus ventajas, al estar totalmente integrada con gvSIG al soportar librerías Java, pero también tiene sus limitaciones, por ejemplo, no todas las librerías de R están disponibles para su uso con Renjin.

“Con Rejin, tenemos una gran integración con gvSIG, pero menor integración con R”

Podéis encontrar mucha más información sobre Renjin en su web, así como las librerías de R que se encuentran disponibles para su uso. Renjin se encuentra activamente en desarrollo, así que esperamos mejoras en el futuro, tanto de compatibilidad como de funcionalidad.

Os voy a mostrar un par de ejemplos. Abrimos gvSIG y vamos a Herramientas – Scripting – Editor de scripts, y aquí creamos un nuevo Script que sea de tipo R.

2016-03-15 10_41_12-Nuevo script

Podemos probar a ejecutar algo del código típico de R como sería:

main <- function() {
cat( "Hello\n" );
cat( "Hello\n" );
d1 <- c(1,3,5);

x <- sample(c("A", "B", "C"), size = 10, replace = TRUE)
print(as.factor(x))

df <- data.frame(x = seq(5), y = runif(5))
print(df)
}

El cual mostraría por consola:

Running script rtest_000.
Hello
Hello
[1] B A B B A C B A A C
Levels: A B C
x y
1 1 0,869
2 2 0,85
3 3 0,255
4 4 0,497
5 5 0,549
Script rtest_000 terminated.

En el siguiente ejemplo vamos a mostrar como importar una clase de Java:

import(java.util.HashMap)

main <- function() {

"Ejemplo renjin con Java"
ageMap <- HashMap$new()
ageMap$put("Bob", 33)
ageMap$put("Carol", 41)
print(ageMap$size())
age <- ageMap$get("Carol")
cat("Carol is ", age, " years old.\n", sep = "")

print(ageMap)

}

Que resultaria por consola:

Running script rtest_001.
[1] 2
Carol is 41 years old.
Script rtest_001 terminated.

Y por último y más interesante, vamos a mostrar como podemos interactuar con gvSIG, accediendo a una de las Vistas que tenemos abiertas para mostrar su nombre, importando las respectivas clases que necesitamos:

import (org.gvsig.app.project.documents.view.ViewDocument)
import (org.gvsig.app.ApplicationLocator)

main <- function() {

cat( "Acceso a una Vista\n" );
application <- ApplicationLocator$getManager();

view <- application$getActiveDocument(ViewDocument);
print(view$name)

}

Mostraría por consola:

Running script rtest_0020.
Acceso a una Vista
[1] "Vista GVISG 01"
Script rtest_0020 terminated.

2016-03-15 10_40_39-gvSIG 2.3.0.2425 RC1 _ Sin título

Aún tenemos que ver la mejor forma de trabajar con Renjin y gvSIG, ya que como hemos comentado, aún estamos en proceso de desarrollo de este módulo.

Cualquier colaboración, interés o feadback que recibamos de vosotros será bien recibido.

Posted in development, gvSIG Desktop, scripting, spanish | Tagged | 6 Comments

OpenStreetMap cartography with reprojected layers in gvSIG 2.x

Posted on 14/03/2016 by Mario

Some time ago, a tool to access to OpenStreetMap cartography was included at the gvSIG 2.0 version. But there was a problem when a layer available in other reference system was added at the same View, that wasn’t reprojected correctly. From the 2.3 gvSIG version this problem has been fixed, so it’s possible to load layers in a different reference system than the used one by OpenStreetMap (EPSG 3857) on the same view.

 

If we have the latest EPSG codes database at gvSIG, that means, the 8.7 JCRS version, we would be able to look for that reference system at the database. The JCRS version used by gvSIG can be selected at the Preferences menu (Show->Preferences menu, and JCRS option). In case another version is used, the 8.7 version can be selected at that window and then restarting gvSIG it will be loaded.

To load OpenStreetMap cartography with reprojected layers on gvSIG 2.x, the first step would be to create a new View with the OpenStreetMap reference system, that means, EPSG 3857. Then to “Add layer”, and “OSM” tab. One of the servers available at that window will be selected, like “Map Quest” for example. The OpenStreetMap cartography will be loaded at the View.

The next step will be to load the local cartography. Some days ago, a post about the reading/writing option for PRJ files from gvSIG 2.3 version was published, so if the layer that we are loading at the View in EPSG 3857 is in a different reference system, and it has a PRJ file, it will be recognized and the layer will be reprojected on the fly. In case the file doesn’t have a PRJ file, its reference system has to be specified.

After that, the layer will be loaded on the OpenStreetMap cartography, on its correct position.

Here you can see a video about that:

 

Posted in english, gvSIG Desktop | Tagged | 1 Comment

Smart Cities: no open source software means no intelligence

Posted on 14/03/2016 by Giuliano Ramat

Right Decision, Wrong Decision Road Sign

Smart City, the intelligent city, has been one of the most fashion concepts in recent years dealing mainly with the use of ICT, information and communication technology, to improve citizens living standards. Technology is not assumed as result itself but as a tool to modernize and optimize city management; in the 21st century technology has been playing, and have to play, a key role in improving public policies. Cities are abandoning the analogic world and, in order to be intelligent, they have to exploit technology.

Let’s try to imagine that public servants, in their decision making activities, choose proprietary software as support for modernization purposes; suppose that they entrust one single supplier for all the technological sectors of our cities, the heart of cities information systems. Although this decision may seem illogical, without any strategic overview, got round such a fundamental topic as technological sovereignty and fill cities management headquarters with black boxes, without leaving any access to informatics components understanding.

Would it be possible to have smart cities or cities would be technologically captives?

The overwhelming logic of the answer is even scarier when we look at its occurring frequency. An important part of municipal budgets is related to these malpractices. Decisions that constrain the future of cities under a broad economic perspective, without forgetting that the economy has also social and knowledge components.

We strengthen the idea that, in the 21st century, cities will be sovereign only if they are technologically independent.

If we add the internal management perspective of the organization to external one, benefits of using free software are immediately added: possibilities of collaboration with other institutions increase and the exorbitant cost to purchase licenses can be shifted to services investment. Services that can be addressed to a local, national company, promoted by administrations. Business network that will require more and better qualified technicians from Universities that will no longer train for brands to shift into training in technology. A synergistic network that perfectly fits the required change in production model.

Making the prospective wider, the answer is even stronger: smart cities are not possible without open source software.

What is the role of geomatics technologies for Smart City land management?

They are the cornerstone; more than 80% of the information handled by a municipality are geographically located: infrastructures, artistic heritage, parks and gardens, socio-economic components, investment … everything is or can be spatially represented.

Spatial Data Infrastructures, therefore, constitute a backbone connecting everything is a Smart City.

Spatial Data Infrastructures 100% open source, as the ones suggested, offered and defended by gvSIG Association.

Posted in english, gvSIG Desktop | 3 Comments

Smart cities: ¿y qué hay de la reutilización?

Posted on 13/03/2016 by Alvaro

imagen proyectosA estas alturas de mi vida profesional todavía me sigo indignando cuando veo licitaciones y subvenciones públicas -y estos últimos años muchas de ellas relacionadas con Smart Cities- en las que básicamente se gasta el dinero de los ciudadanos en adquisición de licencias de software. Licencias con nombres y apellidos en un alto porcentaje de los casos.

En la serie de post iniciada sobre Smart Cities y software libre ya hemos hablado de los motivos por los que una ciudad sólo podrá ser inteligente si garantiza la independencia tecnológica de sus sistemas de información y de que, además, el uso de software privativo ahonda en la discriminación tecnológica entre ciudades de primera y segunda categoría.

Hoy me gustaría incidir en un tema que por mucho que esté en todos los manuales básicos de las Administraciones Públicas, parece que cuando atañe al área del software en la gran mayoría de los casos queda olvidado y relegado a papel mojado. Por mucho que ese papel tenga un carácter legislativo.

Y sí, el tema es el de la Reutilización. Asunto que nos indica que nuestros gestores públicos deberían apostar por soluciones que permitan ser compartidas, reutilizadas, que puedan ser mejoradas y complementadas entre administraciones. En las soluciones informáticas esto sólo es posible con licencias de software libre.

Si en un anterior post hablábamos de que para la gran mayoría de municipios la única opción de subirse al carro de la modernización en la gestión era utilizar software libre, ahora debemos reflexionar sobre el ahorro y el avance tecnológico que se generaría si las soluciones se compartieran. Si se colaborara en su evolución, si se sumaran esfuerzos.

Las necesidades de las ciudades son, básicamente, las mismas en cualquier parte del mundo. Gestión de las infraestructuras (saneamiento y abastecimiento de aguas, alumbrado,…), del patrimonio, del inventario municipal, recogida de residuos sólidos, urbanismo,…las soluciones de software, por tanto, podrían tener una base tecnológica similar. Y si todos estos datos están geoposicionados, la geomática, los sistemas de información geográfica son un eje fundamental en el marco de las Smart Cities. Hablamos desde la práctica y la experiencia de la Asociación gvSIG, a día de hoy el 100% de las necesidades de geomática de cualquier ciudad pueden ser resueltas con totales garantías con software libre.

Y al peso de la lógica de la reutilización hay que sumar las legislaciones vigentes y que son prácticamente equivalentes en todos los países. Veamos el caso de España.

El Esquema Nacional de Interoperabilidad (ENI), regulado por el Real Decreto 4/2010, de 8 de enero, establece el conjunto de criterios y recomendaciones que deberán ser tenidos en cuenta por las AA.PP. para la toma de decisiones tecnológicas que garanticen la interoperabilidad. El ENI se encuentra alineado con la Estrategia Europea de Interoperabilidad y el Marco Europeo de Interoperabilidad. Tanto el ENI, como sus normas técnicas de interoperabilidad, contemplan de manera sistemática el enlace con instrumentos equivalentes del ámbito europeo.

¿Y qué dice sobre la reutilización? En su artículo 16 dice lo siguiente:

Las condiciones de licenciamiento de las aplicaciones y de la documentación asociada, y de otros objetos de información de los cuales las Administraciones públicas sean titulares de los derechos de propiedad intelectual y que éstas puedan poner a disposición de otras Administraciones públicas y de los ciudadanos, sin contraprestación y sin necesidad de convenio, tendrán en cuenta que el fin perseguido es el aprovechamiento y la reutilización, así como la protección contra su apropiación en exclusiva por parte de terceros.

Indica que las Administraciones Públicas deberán tener en cuenta las soluciones disponibles para la libre reutilización que puedan satisfacer total o parcialmente las necesidades de los nuevos sistemas y servicios o la mejora y actualización de los ya implantados.

Y concluye que: el objetivo principal de la liberación de activos es la posible reutilización de los mismos por otros interesados. Las organizaciones, en especial, las administraciones públicas, dedican esfuerzos a crear activos que pueden existir ya. La reutilización de estos activos puede permitir la puesta en común de recursos y resultados, por un lado, en el seno de las administraciones públicas y entre ellas, contribuyendo al ahorro de recursos, esfuerzos y tiempo, y, por otro lado, con la sociedad, contribuyendo al interés social y económico.

¿Bonitas leyes, verdad? Y ahora, ¿nos la tomamos en serio? Apostar por la reutilización es apostar por tecnologías libres. Soberanía tecnológica, reducción de asimetrías y reutilización.

Exijamos gestores inteligentes para tener ciudades inteligentes.

Posted in opinion, spanish | Tagged , , , | 8 Comments

Cartografía de OpenStreetMap con capas reproyectadas en gvSIG 2.x

Posted on 11/03/2016 by Mario

En la versión 2.0 de gvSIG se incluyó el acceso a la cartografía de OpenStreetMap. El problema era que al superponer cartografía disponible en otros sistemas de referencia no se reproyectaban correctamente. A partir de la versión 2.3 de gvSIG ya se ha corregido este problema, por lo que se pueden visualizar capas de sistemas de referencia distintos al utilizado por OpenStreetMap (EPSG 3857).

OSM1

Si se dispone de la última base de datos de códigos EPSG en gvSIG, es decir, la versión JCRS 8.7, ya se podrá también realizar la búsqueda de dicho sistema de referencia. La versión de JCRS con la que arranca gvSIG se podrá comprobar en las preferencias (menú Mostrar-Configuración, opción JCRS). En caso de estar utilizando una distinta se puede seleccionar en dicha ventana la versión 8.7, y reiniciando gvSIG cargará la nueva base de datos.

Para cargar cartografía de OpenStreetMap con capas reproyectadas en gvSIG 2.x, el primer paso será crear una nueva vista en gvSIG, con el sistema de referencia de OpenStreetMap, es decir, EPSG 3857. Después se irá a “Añadir capa” y a la pestaña “OSM”. Se seleccionará uno de los servidores disponibles, como por ejemplo el de “Map Quest”, y se cargará con ello la cartografía de OpenStreetMap en la Vista.

A continuación se cargará la capa que se disponga en local. Como se comentó en un post anterior, a partir de la versión 2.3 de gvSIG también puede leer ficheros PRJ, por lo que si el fichero que estamos cargando en la vista que tenemos en EPSG 3857, está en un sistema distinto y dispone de dicho fichero PRJ, este será reconocido y reproyectará la capa al vuelo. En caso de no disponer del PRJ se le deberá indicar el sistema en el que está la capa que se está cargando.

Finalmente se dispondrá de la capa cargada, sobre la cartografía de OpenStreetMap, en su posición correcta.

Puedes ver un ejemplo en este vídeo:

 

Posted in gvSIG Desktop, spanish | Tagged | 1 Comment