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

5as Jornadas Brasileiras de gvSIG: “Tecnologia como bem comum”

Posted on 09/03/2016 by Mario

É com satisfação que anunciamos a realização das 5as Jornadas Brasileiras de gvSIG nos dias 14 a 16 de setembro de 2016, no Auditório do Centro de Ciências Rurais da UFSM – Santa Maria/RS – Brasil, sob o lema “Tecnologia como bem comum”. O evento representará a quinta reunião formal de usuários e desenvolvedores ligados ao software gvSIG organizada no Brasil.

Banner_5as_Jornadas
Está aberto o período para envio de propostas para comunicações. As formas de participação, bem como as normas e datas limite para a submissão de trabalhos encontram-se no item Comunicações.

Informações e contato: jornadas.brasileiras@gvsig.org

Posted in community, events, gvSIG Desktop, portuguese | 1 Comment

On the road to gvSIG 2.3: New available formats (OGR / GDAL)

Posted on 08/03/2016 by Giuliano Ramat

One of the major architectural changes in gvSIG 2.3 is related to the use of the GDAL library in the frame of raster data and projections. After completed his task, we have decided to create a new access data driver that uses the potentiality of this library in order to be able to access all kinds of formats, since many of them were not supported so far by gvSIG.

What formats are supported by GDAL? Due to the fact that the lists would be so huge, it is much better to share the links:

– Raster formats: http://www.gdal.org/formats_list.html
– Vector Formats: http://www.gdal.org/ogr_formats.html

It is evident that this possibility allows gvSIG users to exploit a much larger number of formats in addition to those already available. We have made this plugin available on the testing server to allow users to test in gvSIG 2.3.

In the following video you can see how to install the plugin through the Add-ons Manager.

Although it is possible that some additional development is required to improve user experience for few formats, there are many formats that have been already testing as shown in the following videos.

Creation of a GeoJSON file and how to load it into gvSIG:

Load MapInfo generated layers both in MID / MIF or TAB format:

Load a GML layer with the cadaster scheme, where the properties of GML to be used in this scheme will be indicated. In this case the GML has been downloaded from geoportal of the Spanish Cadaster General Directorate:

Is it interesting, isn’t it?

Posted in english, gvSIG Desktop | Tagged , , , , , , , , | 2 Comments

On the road to gvSIG 2.3: read and write PRJ files (projections)

Posted on 08/03/2016 by Giuliano Ramat

One of the new features that is coming with the next gvSIG version 2.3 is the capability to read and write PRJ files that was, without any doubt, one of the most requested features by the user community and that will bring considerable advantages.

What is a PRJ?

It is a file that is associated with an information layer (shapefile, raster …) and contains information related to layer coordinate reference system.

If we open a PRJ file with a text editor, variables will be shown in capital letters while values or specifications will be into brackets.

PRJ file information are shown as a single line unformatted text, it is up to different applications to translate and interpret the values contained in the file.

As stated before, starting from gvSIG 2.3, the application will be able to interpret this type of file and automatically identifies the layer projection. In the same way, when a layer is created or exported, the PRJ file is automatically generated.

Let’s have a look to this video showing how projection is automatically detected when loading a couple of layers. In the first case the layer has the same projection system of the View and thus it is added as it is. In the second case, due to its different reference system, gvSIG identifies this difference and automatically performs a reprojection to the View EPSG reference system.

Posted in development, english, gvSIG Desktop | 3 Comments