OSGeo Planet

gvSIG Team: Learning GIS with Game of Thrones (X): Legends

OSGeo Planet - Wed, 2017-03-08 06:20

Today we are going to learn about how to change the symbology of a layer, reviewing different types of legends that are available in gvSIG Desktop.

The symbology is one of the most important properties of a layer. gvSIG includes a great variety of options to represent layers with symbols, graphs and colours. Excepting unique symbol option, the rest of legends are assigned to each element depending on their attribute values and the properties of the type of legend selected.

By default, when a layer is added to a View, it’s represented with a unique symbol with random colour, that means, all the elements of the layer are represented with the same symbol. To modify the symbology of a layer we have to access to its “Properties” window and select “Symbology” tab. We are going to open our “Game of Thrones” project and we will start to explore this part of gvSIG Desktop.

If we want to change a symbol, the easiest way is double-clicking on it at the ToC (Table of Contents with the list of layers). A new window will be opened to select the new symbol. For example we are going to double-click on the symbol of the “Rivers” layer.

At the new window we can change the colour and the width of the line, press on any of the symbol libraries installed (“gvSIG Basic” by default, although we can install a lot of libraries from the Add-ons Manager). In this case we are going to change width to 3 and select a dark blue colour. We press “Accept” to apply changes. 075_got

Now we are going to see the type of legends that are available and we will select a legend by the different types of locations, attribute that we have used in the previous posts. There are a lot of possibilities for symbology, and you can see this additional documentation.

Firstly we will have to open the “Properties” window of the layer. Activating the layer we will find this option at the “Layer/Properties” menu, or directly using the secondary button of the mouse on it. 

Now we access to the “Symbology” tab and a window is shown with the symbology applied. At the left side we can find all the types of symbols than we can use. Warning: Depending on the type of layer (point, line or polygon) we can find different legends available.

In this case we are going to select a legend about “Categories/Unique values”. This type of legend is used to assign a symbol to each unique value specified at the attribute table of the layer. Each element is drawn depending on the value of an attribute that identifies the category. In our case we will select “Type” for classification field; we press “Add all” and it will show the legend created by default:

The Labels (at the right side) can be modified. You can change the texts here.

Now, double-clicking on every symbol a new window will be opened where we can modify them or select new symbols from our symbol libraries with “Select symbol” option. Once they are selected we press “Apply” and we will see the results in our View. 

The best way to learn different type of legends is testing… We also recommend you to install and check the different symbol libraries that are available in gvSIG (hundreds of symbols of all types!!)

See you in the next post…


Filed under: english, gvSIG Desktop, training Tagged: Game of Thrones, legends, symbology
Categories: OSGeo Planet

gvSIG Team: Aprendiendo SIG con Juego de Tronos (XV y final): Instalación de complementos

OSGeo Planet - Wed, 2017-03-08 05:58

Dedicaremos este último post al “Administrador de complementos”, una herramienta que todo usuario de gvSIG Desktop debería conocer.

El administrador de complementos es una funcionalidad que permite personalizar gvSIG, instalando nuevas extensiones, ya sean funcionales o de otro tipo (bibliotecas de símbolos). Se ejecuta desde el menú “Herramientas/Administrador de complementos”, aunque también se puede acceder a él durante el proceso de instalación.

Gracias al “Administrador de complementos” podéis acceder, además de a plugins no instalados por defecto, a todas las nuevas herramientas que se vayan publicando.

En la ventana que aparece lo primero que debéis seleccionar es la fuente de instalación de los complementos:

Los complementos pueden tener 3 orígenes:

  • El propio binario de instalación. El archivo de instalación que nos hemos descargado contiene un gran número de complementos o plugins, algunos de los cuales no se instalan por defecto, pero están disponibles para su instalación. Esto permite poder personalizar gvSIG sin disponer de conexión a internet.

  • Instalación a partir de archivo. Podemos tener un archivo con un conjunto de extensiones listas para instalarse en gvSIG.

  • A partir de URL. Mediante una conexión a Internet podemos acceder a todos los complementos disponibles en el servidor de gvSIG e instalar aquellos que necesitemos.  Es la opción recomendada si se quieren consultar todos los plugins disponibles.

Una vez seleccionada la fuente de instalación, pulsáis el botón de “Siguiente”, lo que nos mostrará el listado de complementos disponibles.

La interfaz del administrador de complementos se divide en 4 partes:

  1. Listado de complementos disponibles. Se indica el nombre del complemento, la versión y el tipo. Las casillas de verificación permiten diferenciar entre complementos ya instalados (color verde) y disponibles (color blanco). Puede ser interesante que revises el significado de cada uno de los iconos.

  2. Área de información referente al complemento seleccionado en “1”.

  3. Área que muestra las “Categorías” y “Tipos” en que se clasifican los complementos. Pulsando en los botones de “Categorías” y “Tipos” se actualiza la información de esta columna. Al seleccionar una categoría o tipo del listado se ejecuta un filtro que mostrará en “1” solo los complementos relacionados con esa categoría o tipo.

  4. Filtro rápido. Permite realizar un filtro a partir de una cadena de texto que introduzca el usuario.

En nuestro caso vamos a instalar una nueva biblioteca de símbolos. Para ello pulsaremos en la categoría “Symbols”, lo que nos filtrará entre los plugins que son “bibliotecas de símbolos”:

A continuación marcamos la biblioteca “G-Maps”:

Pulsamos el botón “Siguiente” y, una vez acabada la instalación, el botón “Terminar”. Un mensaje nos indicará que es necesario reiniciar (en el caso de instalar plugins funcionales es así, pero no es necesario cuando instalamos bibliotecas de símbolos).

Si ahora vamos a cambiar la simbología de alguna de nuestras capas, por ejemplo “Locations”, veremos que ya tenemos los nuevos símbolos disponibles:

Podéis echar un vistazo a las bibliotecas de símbolos disponibles en la documentación.

Y con este último post acabamos este atípico curso de introducción a los SIG. Esperamos que hayáis aprendido y, además, os haya resultado tan divertido como a nosotros hacerlo.

A partir de aquí ya estáis preparados para profundizar en la aplicación e ir descubriendo toda su potencia. Un último consejo…utilizad las lista de usuarios para consultar cualquier duda o comunicarnos cualquier problema con el que os encontréis:

http://www.gvsig.com/es/comunidad/listas-de-correo

Y recordad…gvSIG is coming!

 


Filed under: gvSIG Desktop, spanish Tagged: administrador de complementos, bibliotecas de símbolos, extensiones, Juego de tronos, plugins
Categories: OSGeo Planet

Jackie Ng: React-ing to the need for a modern MapGuide viewer (Part 14): The customization story so far.

OSGeo Planet - Tue, 2017-03-07 14:40
I've been getting an increasing amount of questions lately about "How do you do X?" with mapguide-react-layout. So the purpose of this post is to lay out the customization story so far, so you have a good idea of whether the thing you want to do with this viewer is possible or not.

Before I start, it's best to divide this customization story into two main categories:

  1. Customizations that reside "inside" the viewer
  2. Customizations that reside "outside" the viewer
What is the distinction? Read on.
Customizations "inside" the viewer
I define customizations "inside" the viewer as customizations:
  • That require no modifications to the entry point HTML file that initializes and starts up the viewer. To use our other viewer offerings as an analogy, your customizations work with the AJAX/Fusion viewers as-is without embedding the viewer or modifying any of the template HTML.
  • That are represented as commands that reside in either a toolbar or menu/sub-menu and registered/referenced in your Web Layout or Application Definition
  • Whose main UI reside in the Task Pane or a floating or popup window and uses client-side APIs provided by the viewer for interacting with the map.
These customizations are enabled in our existing viewer offerings through:
  • InvokeURL commands/widgets
  • InvokeScript commands/widgets
  • Client-side viewer APIs that InvokeURL and InvokeScript commands can use 
  • Custom widgets

    From the perspective of mapguide-react-layout, here is what's supported
    InvokeURL commands
    InvokeURL commands are fully supported and do what you expect from our existing viewer offerings:
    • Load a URL (that normally renders some custom UI for displaying data or interacting with the map) into the Task Pane or a floating/popup window.
    • It is selection state aware if you choose to set the flag in the command definition.
    • It will include whatever parameters you have specified in the command definition into the URL that is invoked.
    If most/all of your customizations are delivered through InvokeURL commands, then mapguide-react-layout already has you covered.
    InvokeScript commands
    InvokeScript commands are not supported and I have no real plans to bring such support across. I have an alternate replacement in place, which will require you to roll your own viewer. 
    Client-side viewer APIs
    If you use AJAX viewer APIs in your Task Pane content for interacting with the map, they are supported here as well. Most of the viewer APIs are mostly implemented, short of a few esoteric APIs.
    If your client-side code is primarily interacting with APIs provided by Fusion, you're out of luck at the moment as none of the Fusion client-side APIs have been ported across. I have no plans to port these APIs across 1:1, though I do intend to bring across some kind of pub/sub event system so your client-side code has the ability to respond to events like selection changed, etc.
    Custom Widgets
    In Fusion, if InvokeURL/InvokeScript widgets are insufficient for your customization needs, this is where you would create a custom widget. Like the replacement for InvokeScript commands I intend to enable a similar system once again through custom builds of the mapguide-react-layout viewer.


    My personal barometer for how well mapguide-react-layout supports "inside" customizations is the MapGuide PHP Developer's Guide samples. 


    If you load the Web Layout for this sample in the mapguide-react-layout viewer, you will see all of the examples (and the viewer APIs they demonstrate) all work as before. If your customizations are similar in nature to what is demonstrated in the MapGuide PHP Developer's Guide samples, then things should be smooth sailing.

    Customizations "outside" the viewer
    I define customizations "outside" the viewer as primarily being one of 2 things:
    • Embedding the viewer in a frame/iframe or a DOM element that is not full width/height and providing sufficient APIs so that code in the embedding content document can interact with the viewer or for code in the embedding content document to be able to listen on certain viewer events.
    • Being able to init the viewer with all the required configuration (ie. You do not intend to pass a Web Layout or Application Definition to init this viewer)
    On this front, mapguide-react-layout doesn't offer much beyond a well-defined entry point to init and mount the viewer component.
    Watch this space for how I hope to tackle this problem.
    Rolling your own viewer
    The majority of the work done since the last release is to enable the scenario of being able to roll your own viewer. By being able to roll your own viewer, you will have full control over viewer customization for things the default viewer bundle does not support, such as:
    • Creating your own layout templates
    • Creating your own script commands
    • Creating your own components
    If you do decide to go down this path, there will be some things that you should become familiar with:
    • You are familiar with the node.js ecosystem. In particular, you know how to use npm/yarn
    • You are familiar with webpack
    • Finally, you are familiar with TypeScript and have some experience with React and Redux
    Basically, if you go down this road you should have a basic idea of how frontend web development is done in the current year of 2017, because it is no longer manually editing HTML files, script tags and sprinkles of jQuery.
    Because what I intend to do allow for this scenario is to publish the viewer as an npm module. To roll your own viewer, you would npm/yarn install the mapguide-react-layout module, write your custom layouts/commands/components in TypeScript, and then set up a webpack configuration to pull it all together into your own custom viewer bundle.
    I hope to have an example project available (probably in a different GitHub repository) when this is ready that demonstrates how to do this.
    In Closing
    When you ask the question of "How can I do X?" in mapguide-react-layout, you should reframe the question in terms of whether the thing you are trying to do is "inside" or "outside" the viewer. If it is "inside" the viewer and you were able to do this in the past with the AJAX/Fusion viewers through the extension points and APIs offered, chances are very high that similar equivalent functionality has already been ported across.
    If you are trying to do this "outside" the viewer. you'll have to wait for me to add whatever APIs and extension points are required.
    Failing that, you will have the ability to consume the viewer as an npm module and roll your own viewer with your specific customizations.
    Failing that? 
    You could always fork the GitHub repo and make whatever modifications you need. But you should not have to go that far.
    Categories: OSGeo Planet

    gvSIG Team: Aprende a programar en gvSIG en media hora

    OSGeo Planet - Tue, 2017-03-07 10:16

    Es frecuente que desde la Asociación gvSIG impartamos talleres de scripting en las diversas jornadas gvSIG que se realizan alrededor del mundo. Y es interesante asistir a estos talleres de “observador” porque permite ver como entran alumnos sin ningún conocimiento de programación en gvSIG Desktop y salen con la base necesaria para poder comenzar a desarrollar sus propios scripts en la aplicación.

    Ese es uno de los objetivos principales del scripting, dar a todo tipo de usuarios -no necesariamente programadores- un mecanismo para que de forma muy sencilla puedan desarrollar aplicaciones o herramientas sobre gvSIG Desktop.

    ¿Tan, tan sencillo como para aprender scripting en media hora?

    Ese es el reto que nuestro compañero de la Asociación gvSIG, Óscar Martínez, se ha planteado con el webinar que realizamos en la Universidad Miguel Hernández y del que ahora tenéis disponible el vídeo.

    Reservad media hora de vuestro tiempo y seguid leyendo...


    Filed under: gvSIG Desktop, spanish Tagged: desarrollo, jython, python, quick start, scripting, tutorial
    Categories: OSGeo Planet

    Stefano Costa: Numbering boxes of archaeological items, barcodes and storage management

    OSGeo Planet - Tue, 2017-03-07 08:23

    Last week a tweet from the always brilliant Jolene Smith inspired me to write down my thughts and ideas about numbering boxes of archaeological finds. For me, this includes also thinking about the physical labelling, and barcodes.

    Question for people who organize things for their job. I'm giving a few thousand boxes unique IDs. should I go random or sequential?

    — Jolene Smith (@aejolene) March 3, 2017

    The question Jolene asks is: should I use sequential or random numbering? To which many answered: use sequential numbering, because it bears significance and can help detecting problems like missing items, duplicates, etc. Furthermore, if the number of items you need to number is small (say, a few thousands), sequential numbering is much more readable than a random sequence. Like many other archaeologists faced with managing boxes of items, I have chosen to use sequential numbering in the past. With 200 boxes and counting, labels were easily generated and each box had an associated web page listing the content, with a QR code providing a handy link from the physical label to the digital record. This numbering system was put in place during 3 years of fieldwork in Gortyna and I can say that I learned a few things in the process. The most important thing is that it’s very rare to start from scratch with the correct approach: boxes were labeled with a description of their content for 10 years before I adopted the numbering system pictured here. This sometimes resulted in absurdly long labels, easily at risk of being damaged, difficult to search since no digital recording was made. I decided a numbering system was needed because it was difficult to look for specific items, after I had digitised all labels with their position in the storage building (this often implied the need to number shelves, corridors, etc.). The next logical thing was therefore to decouple the labels from the content listing ‒ any digital tool was good here, even a spreadsheet. Decoupling box number from description of content allowed to manage the not-so-rare case of items moved from one box to another (after conservation, or because a single stratigraphic context was excavated in multiple steps, or because a fragile item needs more space …), and the other frequent case of data that is augmented progressively (at first, you put finds from stratigraphic unit 324 in it, then you add 4.5 kg of Byzantine amphorae, 78 sherds of cooking jars, etc.). Since we already had a wiki as our knowledge base, it made sense to use that, creating a page for each box and linking from the page of the stratigraphic unit or that of the single item to the box page (this is done with Semantic MediaWiki, but it doesn’t matter). Having a URL for each box I could put a QR code on labels: the updated information about the box content was in one place (the wiki) and could be reached either via QR code or by manually looking up the box number. I don’t remember the details of my reasoning at the time, but I’m happy I didn’t choose to store the description directly inside the QR code ‒ so that scanning the barcode would immediately show a textual description instead of redirecting to the wiki ‒ because that would require changing the QR code on each update (highly impractical), and still leave the information unsearchable. All this is properly documented and nothing is left implicit. Sometimes you will need to use larger boxes, or smaller ones, or have some items so big that they can’t be stored inside any container: you can still treat all of these cases as conceptual boxes, number and label them, give them URLs.

    QR codes used for boxes of archaeological items in Gortyna

    There are limitations in the numbering/labelling system described above. The worst limitation is that in the same building (sometimes on the same shelf) there are boxes from other excavation projects that don’t follow this system at all, and either have a separate numbering sequence or no numbering at all, hence the “namespacing” of labels with the GQB prefix, so that the box is effectively called GQB 138 and not 138. I think an efficient numbering system would be one that is applied at least to the scale of one storage building, but why stop there?

    Turning back to the initial question, what kind of numbering should we use? When I started working at the Soprintendenza in Liguria, I was faced with the result of no less than 70 years of work, first in Ventimiglia and then in Genoa. In Ventimiglia, each excavation area got its “namespace” (like T for the Roman theater) and then a sequential numbering of finds (leading to items identified as T56789) but a single continuous sequential sequence for the numbering of boxes in the main storage building. A second, newer building was unfortunately assigned a separate sequence starting again from 1 (and insufficient namespacing). In Genoa, I found almost no numbering at all, despite (or perhaps, because of) the huge number of unrelated excavations that contributed to a massive amount of boxes. Across the region, there are some 50 other buildings, large and small, with boxes that should be recorded and accounted for by the Soprintendenza (especially since most archaeological finds are State property in Italy). Some buildings have a numbering sequence, most have paper registries and nothing else. A sequential numbering sequence seems transparent (and allows some neat tricks like the German tanks problem), since you could potentially have an ordered list and look up each number manually, which you can’t do easily with a random number. You also get the impression of being able to track gaps in a sequence (yes, I do look for gaps in numeric sequences all the time), thus spotting any missing item. Unfortunately, I have been bitten too many times by sequential numbers that turned out to have horrible bis suffixes, or that were only applied to “standard” boxes leaving out oversized items.

    On the other hand, the advantages of random numbering seem to increase linearly with the number of separate facilities ‒ I could replace random with non-transparent to better explain the concept. A good way to look at the problem is perhaps to ask whether numbering boxes is done as part of a bookkeeping activity that has its roots in paper registries, or it is functional to the logistics of managing cultural heritage items in a modern and efficient way.

    Logistics. Do FedEx, UPS, Amazon employees care what number sequence they use to track items? Does the cashier at the supermarket care whether the EAN barcode on your shopping items is sequential? I don’t know, but I do know that they have a very efficient system in place, in which human operators are never required to actually read numerical IDs (but humans are still capable of checking whether the number on the screen is the same as the one printed on the label). There are many types of barcode used to track items, both 1D and 2D, all with their pros and cons. I also know of some successful experiments with RFID for archaeological storage boxes (in the beautiful depots at Ostia, for example), that can record numbers up to 38 digits.

    Based on all the reflections of the past years, my idea for a region- or state-wide numbering+labeling system is as follows (in RFC-style wording):

    1. it MUST use a barcode as the primary means of reading the numerical ID from the box label
    2. the label MUST contain both the barcode and the barcode content as human-readable text
    3. it SHOULD use a random numeric sequence
    4. it MUST use a fixed-length string of numbers
    5. it MUST avoid the use of any suffixes like a, b, bis

    In practice, I would like to use UUID4 together with a barcode.

    A UUID4 looks like this: 1b08bcde-830f-4afd-bdef-18ba918a1b32. It is the UUID version of a random number, it can be generated rather easily, works well with barcodes and has a collision probability that is compatible with the scale I’m concerned with ‒ incidentally I think it’s lower than the probability of human error in assigning a number or writing it down with a pencil or a keyboard. The label will contain the UUID string as text, and the barcode. There will be no explicit URL in the barcode, and any direct link to a data management system will be handled by the same application used to read the barcode (that is, a mobile app with an embedded barcode reader). The data management system will use UUID as part of the URL associated with each box. You can prepare labels beforehand and apply them to boxes afterwards, recording all the UUIDs as you attach the labels to the boxes. It doesn’t sound straightforward, but in practice it is.

    And since we’re deep down the rabbit hole, why stop at the boxes? Let’s recall some of the issues that I described non-linearly above:

    1. the content of boxes is not immutable: one day item X is in box Y, the next day it gets moved to box Z
    2. the location of boxes is not immutable: one day box Y is in room A of building B, the next day it gets moved to room C of building D
    3. both #1 and #2 can and will occur in bulk, not only as discrete events

    The same UUIDs can be applied in both directions in order to describe the location of each item in a large bottom-up tree structure (add as many levels as you see fit, such as shelf rows and columns):

    item X → box Y → shelf Z → room A → building B

    or:

    b68e3e61-e0e7-45eb-882d-d98b4c28ff31 → 3ef5237e-f837-4266-9d85-e08d0a9f4751 3ef5237e-f837-4266-9d85-e08d0a9f4751 → 77372e8c-936f-42cf-ac95-beafb84de0a4 77372e8c-936f-42cf-ac95-beafb84de0a4 → e895f660-3ddf-49dd-90ca-e390e5e8d41c e895f660-3ddf-49dd-90ca-e390e5e8d41c → 9507dc46-8569-43f0-b194-42601eb0b323

    Now imagine adding a second item W to the same box: since the data for item Y was complete, one just needs to fill one container relationship:

    b67a3427-b5ef-4f79-b837-34adf389834f → 3ef5237e-f837-4266-9d85-e08d0a9f4751

    and since we would have already built our hypothetical data management system, this data is filled into the system just by scanning two barcodes on a mobile device that will sync as soon as a connection is available. Moving one box to another shelf is again a single operation, despite many items actually moved, because the leaves and branches of the data tree are naïve and only know about their parents and children, but know nothing about grandparents and siblings.

    There are a few more technical details about data structures needed to have a decent proof of concept, but I already wrote down too many words that are tangential to the initial question of how to number boxes.

    Categories: OSGeo Planet

    gvSIG Team: Aprendiendo SIG con Juego de Tronos (XIV): Mapas

    OSGeo Planet - Mon, 2017-03-06 21:28

    En este penúltimo post del curso para aprender la bases de los Sistemas de Información Geográfica mediante ejercicios prácticos con datos de Juego de Tronos vamos a trabajar con el documento “Mapa”.

    Un documento Mapa es un conjunto de elementos de diseño de un mapa o plano, organizados en una página virtual y cuyo objetivo es su salida gráfica (impresión o exportación a PDF). Lo que se ve en el diseño es lo que se obtiene al imprimir o exportar el mapa al mismo tamaño de página definido. En un Mapa se pueden insertar dos tipos de elementos: Elementos cartográficos y de diseño.

    En nuestro caso vamos a crear un mapa con la ruta seguida por los hermanos Greyjoy y dibujada en el post sobre “Edición gráfica”.

    Una vez tenemos abierto nuestro proyecto en gvSIG, lo primero que haremos es ir a la ventana de “Gestor de proyecto”. Una forma rápida de hacerlo es mediante el menú “Mostrar/Gestor de proyecto”. Seleccionamos el tipo de documento “Mapa” y pulsamos el botón de nuevo. Se nos abrirá una nueva ventana donde definiremos la características de la página de Mapa.

    En nuestro caso seleccionaremos un “Tamaño de página” de “A4”, con “Orientación” “Horizontal” y le indicaremos que utilice la Vista donde tenemos nuestras capas cargadas en lugar de “Crear nueva Vista”. Si tenéis más de una Vista en vuestro proyecto, aparecerá un listado con todas ellas.

    Veréis que crea un nuevo mapa, en el que se ha insertado la Vista indicada y que ocupa toda la superficie de la página:

    Pulsando sobre los “cuadrados negros” que aparecen en las esquinas y puntos medios del rectángulo que define la extensión de la Vista podemos cambiar su tamaño. De este modo vamos definiendo nuestro diseño del mapa. Haciendo clic sobre el elemento Vista insertado y arrastrando podemos desplazarlo. En nuestro caso redimensionamos la Vista insertada y la desplazamos, pasando a continuación a añadir otros elementos cartográficos.

    La mayoría de los elementos cartográficos están íntimamente ligados a un documento Vista, de modo que al realizar cambios en la Vista, pueden verse reflejados en el mapa (cambios de zoom, desplazamientos, modificación de leyendas, organización de capas, etc.). Estas herramientas están disponibles desde el menú “Mapa/Insertar“ y en la barra de botones correspondiente.

    Vamos a comenzar por insertar la leyenda. Esta herramienta está disponible desde el menú “Mapa/Insertar/Leyenda“ o con su botón:

    La leyenda siempre se asocia con una Vista insertada en el Mapa y permite representar la simbología de las distintas capas de esa Vista. Una vez seleccionada la herramienta, se indicará el primer extremo del rectángulo que define el espacio a ocupar por la leyenda haciendo clic sobre el área de Mapa en el lugar deseado, y arrastrando hasta soltar en el extremo opuesto. Se mostrará un cuadro de diálogo en el que puede definir las propiedades gráficas de la leyenda insertada:

    En esta ventana podemos marcar que capas (su simbología) queremos que aparezca en la leyenda.

    A continuación pasamos a insertar un símbolo de Norte. Esta herramienta está disponible desde el menú “Mapa/Insertar/Norte“ y en su botón correspondiente:

    Una vez seleccionada la herramienta, se indicará el primer extremo del rectángulo que define el espacio a ocupar por el símbolo de norte haciendo clic sobre el área de Mapa en el lugar deseado, y arrastrando hasta soltar en el extremo opuesto. Se mostrará un cuadro de diálogo en el que puede definir las propiedades gráficas del norte insertado:

    Y nuestro Mapa tendrá el siguiente aspecto:

    Para finalizar insertaremos un título con la herramienta de “Insertar texto” (en el menú Mapa/Insertar/Texto o en su botón correspondiente). El funcionamiento es similar al de los otros elementos, y en este caso lo que indicaremos es el texto que queremos que aparezca: “Greyjoy Brothers”.

    A partir de aquí y por no alargar demasiado el post os encomendamos a que reviséis la documentación relacionada con el documento Mapa y que vayáis probando a insertar escalas gráficas, cajetines, etc. así como a probar las herramientas de ayuda al dibujo…con práctica os pueden quedar mapas realmente bien diseñados.

    Una vez tengáis vuestro mapa acabado podéis exportarlo a PDF con el botón:

    Ya podéis enviar vuestro archivo PDF a todos vuestros contactos.

    Como suelen decir, la práctica hace al maestro…así que ya sabéis.

    Queda un post para despedir el curso…no os lo perdáis.


    Filed under: gvSIG Desktop, spanish Tagged: Exportar a PDF, Juego de tronos, mapa
    Categories: OSGeo Planet

    Paul Ramsey: Christy Clark's $1M Faux Conference Photo-op

    OSGeo Planet - Mon, 2017-03-06 20:00

    On February 25, 2013, Christie Clark mounted the stage at the “International LNG Conference” in Vancouver to trumpet her government’s plans to have “at least one LNG pipeline and terminal in operation in Kitimat by 2015 and three in operation by 2020”.

    Christy Clark's $1M Faux Conference Photo-op

    Notwithstanding the Premier’s desire to frame economic devopment as a triumph of will, and notwithstanding the generous firehosing of subsidies and taxbreaks on the still nascent sector, the number of LNG pipelines and terminals in operation in Kitimat remains stubbornly zero. The markets are unlikely to relent in time to make the 2020 deadline.

    And about that “conference”?

    Like the faux “Bollywood Awards” that the government paid $10M to stage just weeks before the 2013 election, the “LNG in BC” conference was a government organized “event” put on primarily to advance the pre-election public relations agenda of the BC Liberal party.

    In case anyone had any doubts about the purpose of the “event”, at the 2014 edition an exhibitor helpfully handed out a brochure to attendees, featuring an election night picture of the Premier and her son, under the title “We Won”.

    We Won

    The “LNG in BC” conference continued to be organized by the government for two more years, providing a stage each year for the Premier and multiple Ministers to broadcast their message.

    The government is no longer organizing an annual LNG confab, despite their protestations that the industry remains a key priority. At this point, it would generate more public embarassment than public plaudits.

    Instead, we have a new faux “conference”, slated to run March 14-15, just four weeks before the 2017 election begins: the #BCTech Summit.

    Like “LNG in BC”, the “BCTech Summit” is a government-organized and government-funded faux industry event, put on primarily to provide an expensive backdrop for BC Liberal politicking.

    BC Innovation Council

    The BC Innovation Council (BCIC) that is co-hosting the event is itself a government-funded advisory council run by BC Liberal appointees, many of whom are also party donors. To fund the inaugural 2016 version of the event, the Ministry of Citizens Services wrote a direct award $1,000,000 contract to the BCIC.

    The pre-election timing is not coincidental, it is part of a plan that dates all the way back to early 2015, when Deputy Minister Athana Mentzelopoulos directed staff to begin planning a “Tech Summit” for spring of the following year.

    “We will not be coupling the tech summit with the LNG conference. Instead, the desire is to plan for the tech summit annually over the next couple of years – first in January 2016 and then in January 2017.” – email from A. Mentzelopoulos, April 8, 2015

    The intent of creating a “conference” to sell a new-and-improved government “jobs plan”, and the source of that plan, was made clear by the government manager tasked with delivering the event.

    “The push for this as an annual conference has come from the Premier’s Office and they want to (i) show alignment with the Jobs Plan (including the LNG conference) and (ii) show this has multi-ministry buy-in and participation.” – S. Butterworth, April 24, 2015

    The event was not something industry wanted. It was not even something the BCIC wanted. It was something the Premier’s Office wanted.

    And so they got it: everyone pulled together, the conference was put on, and it made a $1,000,000 loss which was dutifully covered by the Province via the BC Innovation Council, laying the groundwork for 2017’s much more politically potent version.

    This year’s event will be held weeks before the next election. It too will be subsidized heavily by the government. And as with the LNG conference, exhibitors and sponsors will plunk down some money to show their loyalty to the party of power.

    LNG BC Sponsors

    The platinum sponsors of LNG in BC 2015 were almost all major LNG project proponents: LNG Canada, Pacific Northwest LNG, and Kitimat LNG. Were they, like sponsors at a normal trade conference, seeking to raise their profile among attendees? Or were they demonstrating their loyalty to the government that organized the event and then approached them for sponsorship dollars?

    It is hard to avoid the conclusion that these events are just another conduit for cash in our “wild west” political culture, a culture that shows many of the signs of “systematic corruption” described by economist John Wallis in 2004.

    “In polities plagued with systematic corruption, a group of politicians deliberately create rents by limiting entry into valuable economic activities, through grants of monopoly, restrictive corporate charters, tariffs, quotas, regulations, and the like. These rents bind the interests of the recipients to the politicians who create them.”

    Systematically corrupt governments aren’t interested in personally enriching their members, they are interested in retaining and reinforcing their power, through a virtuous cycle of favours: economic favours are handed to compliant economic actors who in turn do what they can to protect and promote their government patrons.

    Circle of Graft

    The 2017 #BCTech conference already has a title sponsor: Microsoft. In unrelated news, Microsoft is currently negotiating to bring their Office 365 product into the BC public sector. If the #BCTech conference was an ordinary trade show, these two unrelated facts wouldn’t be cause for concern. But because the event is an artificially created artifact of the Premier’s Office, a shadow is cast over the whole enterprise.

    Who is helping who here, and why?

    A recent article in Macleans included a telling quote from an anonymous BC lobbyist:

    If your client doesn’t donate, it puts you at a competitive disadvantage, he adds. It’s a small province, after all; the Liberals know exactly who is funding them, the lobbyist notes, magnifying the role donors play and the access they receive in return.

    As long as BC remains effectively a one-party state, the cycle of favors and reciprocation will continue. Any business subject to the regulatory or purchasing decisions of government would be foolish not to hedge their bets with a few well-placed dollars in the pocket of BC’s natural governing party.

    The cycle is systematic and self-reinforcing, and the only way to break the cycle, is to break the cycle.

    Categories: OSGeo Planet
    Syndicate content