This post is about advanced uses of JPEG compression in TIFF/GeoTIFF files. We will call such files "JPEG-in-TIFF" for the sake of shortness.

JPEG-in-TIFF is a popular variation of TIFF, described in TIFF specification supplement 2, well-suited for aerial/satellite imagery, that exhibits an interesting quality / (size * decompression_time) ratio, while remaining a format simple to encode/decode with Free and Open Source software.

Side note: while JPEG 2000 compression is a much more capable format, F.O.S.S. is still trying to catch up with proprietary implementations, although the OpenJPEG library (that can be used through the GDAL JP2OpenJPEG driver) has made recent advances that make it worth to be considered.

JPEG-in-TIFF creation options

To go back to JPEG-in-TIFF, quality/size can be controlled by selecting :

• appropriate subsampling and colorspace. For RGB "natural" images, a good choice is YCbCr colorspace with subsampling of factor 2 on the chrominance difference componants (YCbCr 4:2:0). This is the PHOTOMETRIC=YCbCr creation option in the GDAL GTiff driver. Using it make the size of the image typically 2 to 3 times smaller than the default value for photometric interpretation (RGB)
• the usual JPEG quality parameter that acts on the quantization coefficients. This is the JPEG_QUALITY creation option.

Generally, you will want to generate a tiled version of JPEG-in-TIFF (TILED=YES creation option), so as to be able to access efficiently and in a random way to parts of the image.

Implicit overviews

The very latest improvements added to the GDAL development version (trunk r27226 or later, already deprecating the soon to-be-released GDAL 1.11) make it possible to have faster downsampled versions of JPEG-in-TIFF than before. Despite this improvement, the recommandation remains to generate overviews, either external or internal, with the gdaladdo utility, in order to have very fast access to downsampled versions of a raster (at the expense of increased storage space)

But what can we do when such overviews are not (yet) generated ? Previously, the GTiff driver would decompress the queried part of the raster at its full resolution and compute a downsampled image from it. But this is more slow than needed.

Schematically (voluntary omitting quantization and Huffman compression steps), a JPEG compressed stream is made of a sequence of squares of size 8x8 (or 16x16 with YCbCr 4:2:0) pixels (the technical name for such as block is a MCU, Minimum Code Unit) that contain the coefficients resulting from the Discrete Cosine Transform of the original 8x8 (16x16) pixels. To decompress a MCU to its full resolution, you need to compute the inverse DCT on the whole set of 8x8 (16x16) coefficients, which has some cost. But an interesting property of MCU coefficients is that you only need to operate on the high order ones to compute a lower resolution of the uncompressed block, and libjpeg, the software library that does the low-level job of compressing and decompressing the JPEG codestream, is capable of that ! Actually, we had already used that capability in the GDAL JPEG driver of GDAL 1.10, to expose implicit overview levels (at x2, x4, x8 sub-sampling factors), but it was not yet plugged into the GTiff driver.

Now, JPEG-in-TIFF files, in all possible formulations (tiled / stripped / single-stripped, pixel-interleaved vs band-interleaved, single band vs YCbCr 4:2:0 vs RGB colorspace), will internally expose overview levels at x2, x4 and x8 sub-sampling factors for raster operations.

So computing the 1/16th reduction of a BMNG tile of size 21600x21600, with 256x256 tiling, JPEG RGB compression, now takes about 3.5s with the latest developmenet version about 21s in GDAL 1.11 :

GDAL trunk :
$ time gdal_translate world.topo.bathy.200406.3x21600x21600.B2.tif out.tif -outsize 6.25% 6.25%
real    0m3.441s

GDAL 1.11 :
$ time gdal_translate world.topo.bathy.200406.3x21600x21600.B2.tif out.tif -outsize 6.25% 6.25%
real    0m20.987s

Note that the whole JPEG codestream will still be read from the storage, so the new optimization will be especially worthwile when I/O speed is good w.r.t CPU speed (whereas with JPEG2000 compression, due to the way how wavelet coefficients are packed, you only need to read small portion of the file).

If you try gdalinfo on a JPEG-in-TIFF file, relax if you don't see the implicit overviews mentionned. They are hidden most of the time to avoid confusion : it would be difficult for users to distinguish between internal pre-computed overviews, which benefit from fast acces, and the new implicit overviews. The latter ones are only made visible to the internals of the GTiff driver when a raster operation takes place.

Lossless conversion of JPEG into JPEG-in-TIFF

This is a feature that appeared in GDAL 1.10 released last year, but which has probably been unnoticed in the NEWS. The conversion of a JPEG file to a JPEG-in-TIFF is done without decompression and recompression cycles, through the preservation of the MCU coefficients, making it effectively lossless (the initial JPEG compression was lossy, but the conversion into JPEG-in-TIFF is lossless).
This optimized conversion path is taken if all the following conditions are met :

• the source dataset is a JPEG file (or a VRT with a JPEG as a single SimpleSource)
• the target dataset is a JPEG-in-TIFF file
• no explicity target JPEG quality is specified
• no change in colorspace is specified
• no sub-windowing is requested
• etc...

But it is compatible with the generation of a tiled JPEG-in-TIFF from the original JPEG image. Explicit assigment of target SRS and bounds are also possible.

So, the following commands will use the lossless copy method :

$ gdal_translate in.jpg out.tif -co COMPRESS=JPEG

$ gdal_translate in.jpg out.tif -co COMPRESS=JPEG -co TILED=YES

$ gdal_translate in.jpg out.tif -co COMPRESS=JPEG -a_srs EPSG:4326 -a_ullr -180 90 180 -90

whereas the following commands will NOT :

$ gdal_translate in.jpg out.tif -co COMPRESS=JPEG -co QUALITY=60

$ gdal_translate in.jpg out.tif -srcwin 0 0 500 500 -co COMPRESS=JPEG

Lossless extraction of JPEG tiles from JPEG-in-TIFF

The fresh new jpeg_in_tiff_extract.py Python script (needs GDAL trunk) does (part of) the reverse operation. From a JPEG-in-TIFF, it can extract one particular tile/strip into a standalone JPEG file, and generate the companion .aux.xml file if the source JPEG-in-TIFF is georeferenced.

The following command will extract the tile at column 10 (count starts at 0), row 20 from a tiled JPEG-in-TIFF :

python jpeg_in_tiff_extract.py world.topo.bathy.200406.3x21600x21600.B2.tif out_10_20.jpg 10 20

Or to extract all the tiles (filenames will have the out_X_Y.jpg pattern) :

python jpeg_in_tiff_extract.py world.topo.bathy.200406.3x21600x21600.B2.tif out.jpg

This could be interesting for tiling servers that want to keep global mosaics as sources.

Note: this is not exactly the reverse operation from JPEG --> JPEG-in-TIFF conversion, since it will not merge several JPEG-in-TIFF strips/tiles into a single JPEG file.

Ideas for later...

Instead of the jpeg_in_tiff_extract.py script, we could imagine that the lossless extraction of JPEG from JPEG-in-TIFF could be done, in a natural way, with :

gdal_translate -srcwin X Y XSIZE YSIZE in.tif out.jpg -of JPEG

That would require detecting a sub-windowing pattern in the temporary VRT generated by gdal_translate, and then reassembling the right MCU coefficients. X, Y, XSIZE and YSIZE should be multiple of 8 or 16 to match MCU dimensions.

A more powerful, but even more complicated, idea would be to have first-class support in GDAL for the DCT coefficients, as raster bands ?, but it would require some thinking to find the right modelisation, and even more to implement it (with complications like YCbCr 4:2:0 subsampling).

In a similar vein, why not imagining:

gdal_translate mosaic_of_jpeg_images.vrt out.tif -co COMPRESS=JPEG

To make it easier, the VRT file should be made of JPEG tiles whose dimensions are a multiple of the MCU dimensions, and that are placed into the mosaic at offsets that are themselves multiple of the tile dimensions. An additional constraint is that all the JPEG tiles should share the same JPEG quantization and Huffman tables, since in JPEG-in-TIFF, those tables are common for all tiles/strips and placed in the JPEGTABLES TIFF tag.
Building a JPEG-in-TIFF from a mosaic in the GTiff driver might be tricky, but an ad-hoc Python script might be possible.

I will stop here with science-fiction. There is already enough to experiment !

Il mese scorso abbiamo celebrato la prima #MuseumWeek, una settimana di alta visibilità social per i musei di alcuni paesi, tra cui l’Italia ‒ tutta su Twitter. Se ne è parlato molto tra gli addetti ai lavori e mi sembra che tutti siano rimasti contenti. Anche io ho partecipato alla #MuseumWeek, occupandomi dell’account @archeoliguria della Soprintendenza per i Beni Archeologici della Liguria (dove lavoro). Siamo quasi in fondo alla lista dei musei italiani che hanno aderito ufficialmente.

Già in corso d’opera c’erano state raccolte di dubbi, più sullo svolgimento pratico che sull’iniziativa in generale, come ha scritto Linkiesta. Qui vorrei raccogliere, un po’ per riflessione un po’ per mugugno, alcuni elementi di debolezza che ho colto durante la settimana e che mi sembrano importanti per tutte le prossime volte che parteciperemo a una iniziativa simile.

Anzitutto, i tempi. La #MuseumWeek si è svolta dal 24 al 30 marzo 2014, e la notizia è comparsa sul blog di Twitter il 10 marzo, cioè due settimane prima. Per essere una iniziativa a cui dovevano partecipare centinaia di istituzioni in mezza Europa, il preavviso è stato scarso. Ma il motivo è presto detto: è stata organizzata completamente top-down, con date e tempistiche fissate in anticipo, fino alla definizione degli argomenti da trattare. Mi direte: è il bello del social, l’improvvisazione, e tu sei un bradipo! Vi rispondo che con 5 musei da coordinare distribuiti in tutta la regione, con una infrastruttura tecnologica non proprio all’avanguardia non è stato facile ‒ i bradipi quasi sempre fanno 4 o 5 cose diverse contemporaneamente e non dedicano l’intera giornata ai social media. I bradipi più bradipi sono stati quelli che già durante la #MuseumWeek mandavano e-mail chiedendo di inviare via e-mail dei messaggi di 140 caratteri che poi avrebbero provveduto a far pubblicare su un certo account istituzionale molto seguito…

A chi si iscriveva mandando una e-mail a museumweek2014@gmail.com veniva inviata da Massimiliano D’Ostilio (della società TTA) una breve presentazione in cui si scoprivano i temi del giorno e le modalità previste di interazione. Si tratta secondo me di un documento banale, di taglio puramente promozionale, in cui sono stati elencati solo benefici e nessun rischio (l’ABC della progettazione, credo). Tanto per fare due esempi concreti: i musei italiani hanno corso il rischio di essere insultati per i noti problemi di gestione del patrimonio (durante quella settimana non credo sia successo, ma capita), mentre gli utenti hanno rischiato di trovarsi la timeline inondata di contenuti non sempre interessanti (e credo che in alcuni giorni questo sia successo davvero).

La scaletta delle tematiche era molto adatta a musei grandi e tradizionali, ruotando in modo determinante intorno alle collezioni, le opere e i quadri, insomma non il massimo per piccoli musei e aree archeologiche. In effetti se rileggete il post di presentazione questa preferenza è chiara, dal calibro dei musei citati (e speriamo coinvolti nell’ideazione, almeno loro). Sopra ho scritto che questi sono appunti per la prossima volta che parteciperemo proprio perché la #MuseumWeek, bella ed entusiasmante, era una offerta da prendere o lasciare ‒ anche se qualche museo l’ha interpretata a modo suo.

Ma insomma, tutti questi sono inutili mugugni perché la #MuseumWeek è stata una figata pazzesca e siamo stati nei trending topic per una settimana intera e abbiamo moltiplicato i follower e abbiamo avuto n-mila interazioni… forse. Siamo stati nei trending topic ma eravamo veramente tanti quindi era abbastanza scontato, oltre al fatto che Twitter potrebbe aver deciso di mettere la #MuseumWeek nei trending topic. Abbiamo moltiplicato i follower, indubbiamente, e per molte realtà piccole e agli esordi social questo è stato importante: @archeoliguria è passata nell’arco della settimana da 200 a 300 follower circa. Abbiamo avuto davvero molte interazioni, che non mi sono messo a contare, ma sulla qualità di queste interazioni ho qualche dubbio: anzitutto c’è stato un fortissimo senso di cooperazione tra le realtà medio-piccole e ci siamo fatti coraggio a vicenda, ritwittando i messaggi degli altri musei, commentando e rispondendo alle domande del giorno tra di noi, mentre il pubblico “esterno” ha interagito meno (potrei dire molto meno, se avessi dei numeri). Giornate come #AskTheCurator e #GetCreative hanno mostrato come il pubblico, anche quando si entusiasma, è abbastanza pigro o semplicemente non è abituato a parlare con il museo ‒ anche perché c’è una ampia fetta di popolazione “esperta” di archeologi, storici dell’arte, guide turistiche che forse ha partecipato più per senso di appartenenza che per curiosità verso qualcosa di nuovo. Generalizzando, mi dispiace invece notare come i grandi musei e poli museali abbiano scelto ancora una volta di rimanere in modalità broadcasting, sfruttando tutta la loro visibilità per mostrarsi al pubblico con cui non hanno minimamente interagito. Delle vere superstar. A proposito di superstar, è rimasto un po’ in sordina anche l’esercito sempre più numeroso dei personaggi parlanti che hanno iniziato a popolare Twitter dopo il successo dei due tamarri bronzi di Riace (a proposito: che fine avranno fatto?)

Tutto da buttare? Assolutamente no. Ma non è tutto #oro quel che #luccica e non credo, come ha invece scritto @insopportabile, che Twitter abbia assolto al ruolo di un ministero della cultura organizzando la #MuseumWeek. Il successo lo abbiamo fatto noi ma credo che ci voglia ben altro per trasferire il successo social ai musei in carne e ossa: non dobbiamo vendere niente, ma raccontare tantissimo.

It’s taken slightly longer than I’d like, but I’ve updated Portable GIS to include QGIS 2.2. You can find a copy of this new version on the portable gis page. I’ve included a zip file of the qgis2 folder for those that don’t want to install a full new version. You should be able to simply copy this over the existing apps/qgis2 folder, but you will lose any personalisations, such as new plugins etc that you’ve installed, so you have been warned!

Note that there’s a slight regression with this version- as I’m no longer claiming that QGIS Server and Map Viewer will work. I’ve had all sorts of trouble configuring these to work in the windows environment, let alone portable gis, and I wanted to get this release out without additional delay. When I get chance, I’ll get it finished, and believe me it will deserve a blog post and fanfare all of it’s own.

Also note that this is my first move away from using Dropbox as my file hosting service. Please bear with me if there are any problems with the link!

A estas alturas creo que sobran los motivos para hacer lo posible por estar presentes en las 6as Jornadas gvSIG de Latinoamérica y Caribe que junto a MundoGEO#Connect han convertido a esta cita en ineludible. Además de un amplio abanico de ponencias y una mesa redonda que nadie debería perderse, habrá talleres de formación, sobre los que ya hemos publicado post (1 y 2).

Junto a estos 2 talleres realizaremos un tercero (que yo mismo impartiré) a modo de introducción a la nueva versión gvSIG 2.1

Durante el taller haremos un repaso a las principales funcionalidades de gvSIG y a las novedades que aporta esta nueva versión. De este modo tanto usuarios noveles como avanzados podrán participar en el taller.

Novedades como el nuevo marco de geoprocesamiento, el acceso a servicios como WMTS y OSM, la creación y acceso a bibliotecas de símbolos, gráficas, nuevas leyendas y mucho más será tratado durante este mini-curso. Si esos días estás en el evento…no te lo puedes perder.

Y, como toda actividad de las 6as Jornadas gvSIG LAC, el acceso al taller es totalmente gratuito. Sólo debes inscribirte en la web de las jornadas.

Por último, recuerda que para los talleres debes llevar tú propio laptop. Y aunque los datos necesarios estarán disponibles para los asistentes, a fin de ahorrar tiempo, es recomendable que los hayas descargado previamente. Los puedes descargar en el siguiente enlace.

Y, por supuesto, lleva instalado gvSIG 2.1.

Cualquier duda que tengas con las instalación puedes enviarla a la lista de usuarios del proyecto.

Filed under: events, gvSIG Desktop, spanish, training Tagged: gvSIG 2.1, LAC

What presentations do you want to see at FOSS4G?  Now is the time to tell us!

The FOSS4G community at large can now read and score potential presentations.  The conference committee will use the aggregate scores from the community review process to help choose which presentations to accept, and to assign presentations to appropriately sized rooms.

The community review process is an important part of creating a conference that benefits and reflects the community. Your input is a significant part of what makes FOSS4G a great conference. Note that you do not need to be registered for the conference to vote. And remember, all presentations will be available online, so even if you are unable to attend, your vote matters.

You can vote now at: http://community-review.foss4g.org.

Please complete your voting by May 5th.

Last week, Boundless and others hosted the first ever QGIS U.S. User Group meeting with 75 attendees at OpenGovHub in Washington DC.

The event attracted a diverse group of experts and novices from organizations as varied as NOAA, the World Bank, USAID, the American Red Cross, Deloitte, LockHeed Martin, the CDC and many others. As a new member of QGIS community myself, I was floored by the energy of the group and how quickly the project is evolving.

Building QGIS

The day started with Jeff Johnson and Larry Shaffer setting the stage with presentations highlighting the history and evolution of QGIS from a shapefile viewer to full-fledged desktop application. Jeff went into detail about specific applications of QGIS, highlighting examples from NOAA and NASA. Larry picked it up from there and discussed the QGIS ecosystem and open source development community. He noted that plug-in development has been a long-time focus within the community and sees core development picking up steam in the coming year.

Next, Tim Sutton from the QGIS project steering committee joined remotely. Thanks to OpenGovHub’s fantastic conference abilities, Tim being in South Africa didn’t pose a challenge. Tim provided further context to Larry’s discussion on core and plugin development and the steering committee’s focus for 2014.

Later on, Gary Sherman joined remotely from Alaska and provided a brief history of QGIS development, including it’s origin as a shapefile viewer. Gary is also the author of the PyQGIS Programmer’s Guide on developing QGIS Plugins.

QGIS for Humanitarianism

After the remote sessions, Kate Chapman of the Humanitarian OpenStreet Map Team gave us an overview of InaSAFE, a QGIS plugin for emergency preparedness and response.

Vivien Depardy and Yewondwossen Assefa of GFDDR then presented on the role QGIS (and GeoNode) plays in their emergency response and disaster recovery efforts. Larry provided context to their efforts, applauding their development model calling it a leading example of development.

Workshops

After a quick lunch we split into two groups for hands-on workshops. Jeff Johnson led “Using QGIS with OpenGeo Suite” and Larry Shaffer led “How to Become a QGIS Developer”. I attended Jeff’s session, which provided a good opportunity to review the fantastic QGIS documentation with an experienced instructor. Jeff used the documentation as a starting point but added his tips and tricks along the way. He ended by showing us how to use the OpenGeo Explorer plugin to publish data to GeoServer.

My colleague, Eva Shon, attended Larry’s workshop. Larry’s goal was to get more developers involved on the QGIS project. As the only core developer in the United States, he’s especially interested in increasing the number of developers from North America. He shared an early draft of QGIS core developer documentation and virtual machine images he’s working on intended to help new developers get started more quickly.

Next Steps

Whether you were looking for an introduction to QGIS or were already active in the community, the day had something for everyone. The event ended with a happy hour and the only question left was when we’d do it again. To learn more about QGIS, download and install it using the OpenGeo Suite installer and check out documentation to see what it can do. Stay tuned for next QGIS U.S. User Group meetings being planned in Atlanta and Seattle.

The post QGIS US User Group: The beginning of something big appeared first on Boundless.

El referente en el desarrollo de soluciones tecnológicas de Gestión Territorial aplicadas a los sectores de “Agua”, “Energías renovables” y “Mobilidad”, el Centro Internacional de Hidroinformática (CIH) es un centro binacional, resultado de la colaboración entre el Gobierno de Brasil y el de Paraguay, ITAIPU Binacional y el Programa Internacional (PHI) de la UNESCO. Además de su carácter binacional es un Centro de Categoría 2 de la UNESCO, es decir, sus actividades están avaladas por la Organización de las Naciones Unidas para la Educación, la Ciencia y la Cultura .

Los proyectos e iniciativas promovidas por el CIH fomentan una gestión sostenible de los recursos hídricos y las energías renovables, teniendo como área estratégica de actuación la Cuenca Hidrográfica del Paraná. Sus actividades tienen como objetivo la investigación territorial por medio del estudio y levantamiento de datos, el análisis e interpretación de estos y la presentación de soluciones viables valorando tanto cuestiones técnicas como ambientales, sociales y económicas, así como la virtualización de estos datos por medio de los Sistemas de Información Geográfica, habiendo sido seleccionada como herramienta estratégica gvSIG.

De este modo, el CIH, por medio del Analista Ambiental Alisson Rodrigues Alves, realizará el Curso de Geoprocesamiento com Software Libre. El curso utilizará el software libre gvSIG que posibilita la visualización de datos cuantitativos del territorio y su análisis espacial mediante mapas temáticos interactivos. gvSIG también permite cruzar datos diversos para la toma de decisiones y actuaciones sobre el territorio, para los más diversos ámbitos.

El objetivo del curso será formar a profesionales y/o académicos del área de Geomática -y otras relacionadas- en el uso de gvSIG, mediante diversos ejercicios prácticos de geoprocesamiento y gestión territorial con énfasis en el nexo Agua-Energía.

Los temas abordados durante el curso serán:

• Introducción a teledetección

• Definición del nexo Agua-Energía

• Nociones teóricas de geoprocesamiento y cartografía

• Características de los SIG

• Aplicaciones prácticas de catastros técnicos multifunción.

La formación estará enfocada a los geoprocesos relacionados con los objetivos específicos del CIH, como el desarrollo técnico regional aplicado a la gestión de recursos hídricos y energías renovables.

Para llevar a cabo el curso los interesados necesitan estar inscritos en las 6as Jornadas gvSIG de Latinoamérica y Caribe y ser usuarios a nivel básico de SIG. Los participantes deberán utilizar sus laptops con gvSIG (1.10 recomendada) previamente instalado. Los datos y archivos necesarios serán suministrados durante el propio curso.

Filed under: events, gvSIG Desktop, spanish Tagged: LAC

April 22, 2014
Portland, OR, USA

Community voting open through May 5th

What presentations do you want to see at FOSS4G?  Now is the time to tell us!  

The FOSS4G community at large can now read and score potential presentations.  The conference committee will use the aggregate scores from the community review process to help choose which presentations to accept, and to assign presentations to appropriately sized rooms.

The community review process is an important part of creating a conference that benefits and reflects the community. Your input is a significant part of what makes FOSS4G a great conference. Note that you do not need to be registered for the conference to vote. And remember, all presentations will be available online, so even if you are unable to attend, your vote matters.

You can vote now at: http://community-review.foss4g.org/.  

Please complete your voting by May 5th.

Important Conference Dates

See the full calendar for more details.

• June 15th: Early bird registration ends
• Sept 8th-9th: Workshops
• Sept 10th-12th: Main Conference
• Sept 13th: Code Sprint

About FOSS4G

The annual FOSS4G conference is the largest global gathering focused on open source geospatial software. FOSS4G brings together developers, users, decision-makers and observers from a broad spectrum of organizations and fields of operation. Through six days of workshops, presentations, discussions, and cooperation, FOSS4G participants create effective and relevant geospatial products, standards, and protocols.

FOSS4G has been held all over the world and draws attendees from over 40 countries. Nottingham, England hosted the conference in 2013. In 2014, Portland, Oregon, USA will host FOSS4G’s tenth year.

About OSGeo

The Open Source Geospatial Foundation (OSGeo) was founded in 2006 to support and build the highest-quality open source geospatial software. The foundation's goal is to encourage the use and collaborative development of community-led projects, data development and education. Many projects live under the OSGeo umbrella, including FOSS4G, http://osgeo.org.

About PDX-OSGeo - Portland Area and Oregon OSGeo Chapter

The PDX-OSGeo chapter of OSGeo has been meeting, discussing and promoting the use of open source geospatial technology since 2009. Chapter members often organize or present on open source software at regional geospatial conferences. PDX is the airport code and like the PDX airport, the group has a wide catchment area.

---

Sponsors

 

Silver Level Sponsors

        
 

Bronze Level Sponsors

                                                        
       
 

Supporters

                                                              

 

Media Partners

These leading geospatial media organizations have partnered with FOSS4G to keep their readers informed.

                           
                           
                                      
                              
 

---

For more information or to keep informed from the FOSS4G Organizing Committee, follow @foss4g on Twitter, subscribe to our announcements list, or contact: foss4g2014-info@osgeo.org

Darrell Fuhriman, Chair of the FOSS4G Organizing Committee, email: darrell@garnix.org

Referência no desenvolvimento de soluções tecnológicas para Gestão Territorial aplicadas à “Água”, “Energias Renováveis” e “Mobilidade”, o Centro Internacional de Hidroinformática (CIH) é um centro binacional, resultado da parceria entre o Governo do Brasil e do Paraguai, ITAIPU Binacional e Programa Internacional (PHI) da UNESCO. Além de binacional, é um Centro de Categoria 2 da UNESCO, ou seja, suas atividades são chanceladas pela Organização das Nações Unidas para a Educação, a Ciência e a Cultura.

Os projetos e iniciativas promovidas pelo CIH fomentam a gestão sustentável de recursos hídricos e energias renováveis, tendo como área estratégica de atuação a Bacia Hidrográfica do Paraná 3. Sua atuação tem como foco a Investigação Territorial, através do estudo e levantamento de dados, do entendimento e interpretação destas informações, a apresentação de soluções viáveis levando em conta questões técnicas, ambientais, sociais e econômicas, e, por fim, a virtualização dos dados instrumentada em Sistemas de Informações Geográficas – SIG, tendo como ferramenta estratégica o gvSIG.

Deste modo, o Centro Internacional de Hidroinformática, por meio do Analista Ambiental Alisson Rodrigues Alves, ministra o Curso de Capacitação em Geoprocessamento com Software Livre. Para isso, o curso utilizará o software livre gvSIG, que possibilita a visualização de dados quantitativos do território pela espacialização das informações em mapas temáticos interativos. O gvSIG também permite cruzar informações diversas para a tomadas de decisões e atuações territoriais, de forma acessível a todos os âmbitos.

O objetivo do curso é capacitar profissionais e/ou acadêmicos da área de Geomática – e outras correlacionadas, para utilização do software gvSIG, desenvolvendo experiências com geoprocessamento visando a gestão territorial com enfase no Nexo Água-Energia.

Os temas abordados durante o curso são:

• Introdução ao sensoriamento remoto;

• Definição do Nexo Água-Energia;

• Noções teóricas de geoprocessamento e cartografia;

• Características dos Sistemas de Informações Geográficas e,

• Aplicações práticas do Cadastro Técnico Multifinalitário.

A capacitação terá foco nos geoprocessos ligados aos objetivos específicos do Centro Internacional de Hidroinformática, como o desenvolvimento técnico regional aplicado à gestão de recursos hídricos e energias renováveis.

Para realizar o curso, o interessado precisa estar devidamente inscrito via formulário de inscrição da 6as Jornadas da América Latina e do Caribe de gvSIG e ser usuário nível básico de sistemas de informação geográfica. Os participantes deverão utilizar notebooks com gvSIG (recomenda, versão 1.10) previamente instalada para execução das atividades práticas. Os dados e arquivos necessários serão disponibilizados durante o curso.

Filed under: events, gvSIG Desktop, portuguese Tagged: geoprocessamento

Dear All, in this post we would like to talk about the work we are doing to improve support in GeoServer for serving Meteorological and Oceanographic data, specifically the ability to render raster data for wind models using Wind Barbs. When ingesting and serving MetOc models (raster data) for Wind data you are now already able to render  them using an arrow symbology by concatenating:

• the gs:rasterAsFeatureCollection Rendering Transformation to transform the raster dataset into a series of vector points where the bands of the input raster data are the attributes
• a vector style to create arrows for each point with proper module and rotation controlled by the module and direction of the Wind data

With this approach you can obtain something like the following: [caption id="attachment_1438" align="aligncenter" width="512"] Rendering GFS Wind Model data as arrows in GeoServer[/caption] There are a few drawbacks in this approach which are trying to improve in GeoServer, namely:

1. it is not uncommon to draw too many symbols depending on the resolution of the underlying data which makes the visualization slow and cluttered. It is possible to use the standard techniques in GeoServer to reduce the cluttering but this happens once you have generated the vector points with the gs:rasterAsFeatureCollection Rendering Transformation hence it is a slow process (think about collision detection and conflict resolution)
2. meteorologists want Wind Barbs and not simple arrows

We are currently working to improve point 1, we will describe that work in a different post. As of point 2 we are going to provide native support for Wind Barbs by developing a new graphic factory for GeoServer (actually for its rendering engine which is developed using GeoTools) which would allow to render vector points a as Wind Barbs this way: <WellKnownName>windbarbs://default(<ogc:PropertyName>speed</ogc:PropertyName>)[m/s]</WellKnownName> which allows us to:

• extract the speed from the respective speed attribute (yes, we have renamed the underlying raster band to speed)
• specify the unit of measure of the speed. Note that Wind Barbs always deal with speed in knots. Therefore, specifying the input unit of measure allows the factory to do the proper conversion to knots.

rotation can be applied as usual for point vector symbologies. The full style can be found here below:

<StyledLayerDescriptor version="1.0.0"
 xmlns="http://www.opengis.net/sld" xmlns:gml="http://www.opengis.net/gml"
 xmlns:ogc="http://www.opengis.net/ogc" xmlns:xlink="http://www.w3.org/1999/xlink"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.opengis.net/sld ./StyledLayerDescriptor.xsd">
   <NamedLayer>
     <Name>Wind</Name>
     <UserStyle>
       <Title>Wind</Title>
       <FeatureTypeStyle>
         <Transformation>
           <ogc:Function name="gs:RasterAsPointCollection">
             <ogc:Function name="parameter">
               <ogc:Literal>data</ogc:Literal>
             </ogc:Function>
          </ogc:Function>
        </Transformation>
        <Rule>
          <PointSymbolizer>
            <Graphic>
              <Mark>
                <WellKnownName>windbarbs://default(<ogc:PropertyName>speed</ogc:PropertyName>)[m/s]</WellKnownName>
                <Stroke>
                  <CssParameter name="stroke">#000000</CssParameter>
                  <CssParameter name="stroke-width">1</CssParameter>
                </Stroke> 
                <Fill>
                  <CssParameter name="fill">
                    <ogc:Literal>#f5ffff</ogc:Literal>
                  </CssParameter>
                </Fill>
              </Mark>
              <Size>8</Size>
              <Rotation>
                <ogc:PropertyName>direction</ogc:PropertyName>
              </Rotation>
            </Graphic>
          </PointSymbolizer>
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>

  notice the usage of the gs:RasterAsPointCollection Rendering Transformation to turn the raster into a series of vector points. This feature is being developed as we speak, it will be first available on the development series of GeoServer (2.6.x) and then will be backported to 2.5.x. More on the work that we are doing for improving the support for Meteorological and Oceanographic data will be reported in the next posts. It is worth mentioning that this work is being performed under our GeoSolutions Enterprise Services framework contract. If you are interested in learning about how we can help you achieving your goals with our Open Source products and professional services, do not hesitate to contact us! The GeoSolutions team,

En el marco de las Jornadas LAC de gvSIG, que este año se realizan conjuntamente con el evento MundoGEO#Connect, serán realizados varios talleres de los que iremos ampliando información en este blog. Este taller sobre “Cuencas hidrográficas” será impartido por el profesor Gilberto Cugler tiene como objetivo mostrar la facilidad de generar los limites de cuencas y subcuencas hidrográficas utilizando las distintas herramientas disponibles en gvSIG.

Los ejercicios se realizarán sobre un área de aproximadamente 2000 km2, donde será delimitada la cuenca del Río Verde del municipio de Tapiraí, estado de São Paulo (Brasil) con una extensión de 35 km y un área de 317 km2. El proceso de delimitación de la cuenca utilizará también el número de Strahler y otros algoritmos que permiten realizar el análisis morfométrico de una cuenca hidrográfica.

Los datos necesarios para el taller están disponibles en: http://www.sigrb.com.br/capacitacao/6as_lac.php opción 6as Jornadas da América Latina e do Caribe de gvSIG – 2014, tal y como muestra la imagen

Los asistentes al taller deberán traer su laptop con gvSIG y los datos indicados previamente instalados.

Para facilitar el desarrollo de los ejercicios previstos para el taller se recomienda utilizar el mismo lugar de trabajo; para esto se debe instalar el archivo gvSIG_1.11_SIG-RB_portable_PT_BR.exe aceptando como carpeta la propuesta (SigRibeira) y posteriormente descomprimir en esta carpeta los datos (Dados_6LAC.zip).

Para cualquier problema en descargar los archivos o con los datos estamos a disposición en sigrb@sigrb.com.br o gilbertocugler@gmail.com

Filed under: events, gvSIG Desktop, spanish

One of the objectives that we had set for gvSIG 2.2 was to have 64 bits distributions to avoid the possible installation problems that mainly Linux users found.
Nevertheless the process has been faster than we expected and there’s a gvSIG 2.1 distribution for Linux 64bits already. If you are interested in testing it you can find it at the usual development versions downloads page.

---

Uno de los objetivos que nos habíamos marcado para gvSIG 2.2 era disponer de distribuciones de 64 bits para evitar los posibles problemas de instalación que principalmente se encontraba el usuario de Linux.
Sin embargo el proceso ha sido mucho más rápido de lo que esperábamos y ya tenemos disponible una distribución de gvSIG para Linux de 64 bits. Si estás interesado en testearla la puedes encontrar en el sitio habitual de descarga de versiones en desarrollo.

Filed under: english, gvSIG Desktop, spanish, testing Tagged: 64, linux

The necessary tasks in gvSIG 2.1 for maintenance and management of translations in the different languages have been carried out already. Now they have to be updated in order to have the final version with as many languages as possible.

The participation of the Community is fundamental in order to get this objective.

If you are interested in collaborating with the existing languages updating, as well as in translating gvSIG 2.1 to a new language you can contact the gvSIG Project [info@gvsig.com].

Translations that aren’t finished when the final version is released will be published as a package to be loaded from the gvSIG Add-ons manager.

---

Llamamiento a la Comunidad gvSIG: traducciones

Ya se han realizado las tareas necesarias en gvSIG 2.1 para la gestión y mantenimiento de traducciones en los más diversos idiomas. Ha llegado el momento de actualizarlas de cara a tener la versión final disponible en el mayor número de idiomas posible.

Para conseguir este objetivo la participación de la Comunidad es fundamental.

Si estáis interesados en colaborar en la actualización de cualquiera de los idiomas ya existentes en versiones anteriores, así como en traducir gvSIG 2.1 a un idioma nuevo os podéis poner en contacto con el proyecto [info@gvsig.com].

Las traducciones que no estén finalizadas en el momento de la publicación de la versión final se publicarán como paquetes que podrán ser cargados directamente desde el Administrador de complementos de gvSIG.

Filed under: community, english, gvSIG Desktop, spanish

The State of the Map US 2014 conference, a two-day conference covering all things OpenStreetMap, was held this past weekend in Washington DC. It was nice to attend as part of the Boundless contingent and meet — in person — tons of people whom I had only heretofore known via the internets.

Aside from the inspiration provided by the gorgeous weather and the cherry blossoms, there was also inspiration in abundance at the conference for cartographers. Every cartographer should become familiar with OpenStreetMap data if they aren’t already. It’s a bit of a bear to work with because it is in a different structure than we are normally used to (nodes and ways mean anything to you?) but you’ll see the benefits if you download a state-wide or city-wide extract from one of several sites (such as geofabrik or Metro Extracts) and start using it in your map-making medium of choice. The dataset provides a comprehensive collection of roads, buildings and building types, points of interest, and so on. And it’s free!

There were many talks I didn’t get to see because there were two concurrent tracks, but the ones that I attended focused heavily on tools that for using OpenStreetMap data, including GeoGit, TileMill, Esri, QGIS, and PostGIS. However, there were still some cartographic takeaways.

• Kate Watkins, Seth Fitzsimmons and Alan McConchie told us that a great way to build a stylistically cohesive basemap is to focus on three main hues, along with variations on those hues.

• In that same talk we saw some great examples of labels that break all the rules: the leading and kerning (that’s line spacing and character spacing, basically) are decreased to negative values and the halos are very large and black. Of course this is the opposite of what most texts will recommend but it just proves that breaking the rules once in a while can make for some neat cartographic effects.

• Eric Theise showed us that applying some of the devices of experimental film to maps, such as perception distortion, can be a creative way to get people thinking. Eric and I were discussing this later on in the day when he mentioned that he thought it would be interesting to have a map that taunted you if you tried to click on a feature to find out more about it. Something like, “You’d like to know what this building is, wouldn’t you?!”

• Kevin Bullock told a great story about a map of India that was produced in the 1800s with crude tools, took 70 years to complete, and astonishingly accurate despite these and other limitations. And you thought your map products took a long time to produce!

• Our own Jeff Johnson rounded out the weekend with a more technical talk that examined the ways in which GeoGit could lead to a more distributed and decentralized architecture for OSM.

There was a lot more material covered, of course, and these points focused just on the cartography aspect of OpenStreetMap use. All the talks are now posted on the schedule part of the conference website so definitely take the time to watch them!

If you’re still curious about State of the Map, I recommend this great recap from Peter Batty which provides more details about the event and reviews other issues in the OpenStreetMap community including vector tiles, licensing, passive crowdsourcing, geocoding and more.

The post Thoughts from State of the Map US 2014 appeared first on Boundless.

The time for procrastination dwindles…

Regular Sessions and Academic Tracks are both due today.

 

Bonus points to anyone who knows where in PDX this clock is located.

 

 

Summary I spent the past weekend in Washington DC for State of the Map (SotM) US, the OpenStreetMap conference. It ended up selling out, with around 500 attendees, making it the largest OpenStreetMap event yet. As with previous SotM events I’ve attended (the last one being in Denver in 2011), I found it very enjoyable and interesting, and there was great energy about it as always, much more than

The release of OpenGeo Suite 4.0 added Catalogue Services for the Web (CSW) support to the impressive list of OGC services supported by the product. CSW is an open standard defined by the Open Geospatial Consortium (OGC) that makes it easier to search for and discover geospatial data in a machine-readable way. With CSW support, metadata about data and web services is more discoverable, making it easier to manage and advertise data as holdings grow. We explained how to install the CSW plugin and described the mechanics of how a CSW service works in a previous post, but this post will describe how to harvest metadata from GeoServer.

Because CSW can be automatically harvested, its easier to integrate new services into existing spatial data infrastructures. GeoServer offers a minimal implementation of the CSW specification that is limited when compared to implementations in more full-fledged catalogs. This is by design, as it is meant to be as lightweight as possible while still providing the capability to offer metadata about the contents of a GeoServer instance. This metadata can easily be consumed by a more complete CSW implementation that supports harvesting. While specific to GeoNetwork, the same workflow is possible with other servers such as pycsw or Esri GeoPortal Server.

Getting Started

The first step is to install OpenGeo Suite with the CSW plugin. For this post we used OpenGeo Suite 4.0.2 and the installation instructions from our previous post. Once the source catalog is installed, the next step is to download and install a catalog into which to harvest metadata. For this post we used GeoNetwork 2.10.2 and followed the detailed instructions in the documentation.

We installed both OpenGeo Suite and GeoNetwork on the same local machine so all links reference http://localhost. One important note is that since OpenGeo Suite and GeoNetwork use the same default port (8080), one must be changed if you intend to run them on the same machine. For this post we set OpenGeo Suite to run on port 9080 by following the documentation.

Configuring Harvesting

Once OpenGeo Suite is up and running, visit the GeoServer administration page at http://localhost:9080/geoserver. If the CSW plugin has been installed correctly, you’ll see a link to the capabilities document on the right hand side of the page. Copy this link as you’ll need it shortly.

Ensure that GeoNetwork is started and visit http://localhost:8080/geonetwork. Login with the “admin” account — by default the password for this account is “admin”. Once logged in, visit the “Administration” page and go to the “Harvesting Management” link about halfway down the page.

The harvesting page allows us to add a link to another CSW from which to harvest metadata. The goal here is to harvest from GeoServer. Start by clicking the “Add” button, then expand the “Type” drop down and select “Catalogue Services for the Web ISO Profile 2.0”.

This results in a form requesting information about the server from which to harvest. For this step we must fill out the following:

• Set “Name” to “GeoServer CSW” and “Service URL” to the capabilities url we copied previously.

• Uncheck “Use account” since in this case our CSW is not secured by a username and password.

• Choose “Datasets” under the “CATEGORIES” list.

Once the service has been added, return to the harvesting page and select the “GeoServer CSW” service, then click the “Run” button. After a few seconds click the “Refresh” button. Upon success you should see the “Last run” timestamp updated.

Search & Discover

Once the harvest job has completed, GeoNetwork should have all the metadata provided by GeoServer. In this example, GeoServer is publishing a number of layers featuring Natural Earth data. Let’s examine one such layer: parks and protected areas.

Metadata from GeoServer such as title, abstract, and keywords have all been defined. Once GeoNetwork has harvested all this metadata it becomes possible to search using the form on the GeoNetwork home page. As expected, entering the search term “parks” returns on the appropriate layer.

Since the metadata returned by GeoServer provides information about other services, such as WMS, we can browse the data directly in GeoNetwork as well.

The post Harvesting Metadata from OpenGeo Suite using CSW appeared first on Boundless.

Before we continue our blogging journey into the rest of mapguide-rest's data publishing framework, here's the second release of mapguide-rest.

Here's what this new release offers

ACLs for published data sources

We now let you have some level of control as to what users and groups can access a given published data sources, which is important if you are exposing representations that support POST/PUT/DELETE operations and even more important if this is on a public-facing site. You don't want Joe Anonymous MapGuide user to be able to POST/PUT/DELETE to your data sources willy nilly unless you have configured such data sources to allow for such things to happen.

Consider this example from a recent post

{
    "Source": {
        "Type": "MapGuide",
        "FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
        "FeatureClass": "SHP_Schema:Parcels"
    },
    "Representations": {
        "xml": {
            "Adapter": "FeatureSetXml",
            "Methods": {
                "GET": {
                    "MaxCount": 500
                },
                "POST": {},
                "PUT": {},
                "DELETE": {}
            }
        }
    }
}

This configuration will now deny all users because no ACLs have been defined for it. A configuration like this

{
    "Source": {
        "Type": "MapGuide",
        "FeatureSource": "Library://Samples/Sheboygan/Data/Parcels.FeatureSource",
        "FeatureClass": "SHP_Schema:Parcels"
    },
    "Representations": {
        "xml": {
            "Adapter": "FeatureSetXml",
            "Methods": {
                "GET": {
                    "MaxCount": 500,
                    "AllowGroups": ["Everyone"]
                },
                "POST": {
                    "AllowUsers": ["Administrator", "Author"]
                },
                "PUT": {
                    "AllowUsers": ["Administrator", "Author"]
                },
                "DELETE": {
                    "AllowUsers": ["Administrator", "Author"]
                }
            }
        }
    }
}

This will define the following access rules:

• GET: Anybody can access the data source
• POST: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.
• PUT: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.
• DELETE: Only the Administrator and Author users (and related session IDs) can access the data source. Everyone else will be denied access.

Auto-API documentation for published data sources

Thanks to the integration of Swagger UI for our REST API documentation needs, and the fact that all published data sources will offer a "fixed" REST API to interact with it, we now can provide automatic REST API documentation for any published data source.

Simply append a doc/index.html to access a data source's API documentation



New REST API routes

This release includes plenty of new routes to play with

• GET /library/{resourcePath}.WebLayout/viewer (Load the given Web Layout into the AJAX viewer)
• GET /library/{resourcePath}.ApplicationDefinition/viewer/{template} (Load the given Flexible Layout in Fusion with the given template)
• POST /library (Load a package file into the repository)
• GET /services/getschemamapping.{type} (Get the schema mapping for a given FDO provider and partial connection string)
• GET /library/{resourcePath}.FeatureSource/preview (Launch a schema report preview on the given Feature Source)
• GET /library/{resourcePath}.LayerDefinition/preview (Launch a AJAX viewer preview of the given Layer Definition)
• GET /library/{resourcePath}.MapDefinition/preview (Launch a AJAX viewer preview of the given Map Definition)
• GET /library/{resourcePath}.SymbolDefinition/preview (Render a preview of the given Symbol Definition)
• GET /library/{resourcePath}.WatermarkDefinition/preview (Launch a AJAX viewer preview of the given Watermark Definition)
• GET /session/{sessionId}/{resourceName}.WebLayout/viewer (Load the given Web Layout into the AJAX viewer)
• GET /session/{sessionId}/{resourceName}.ApplicationDefinition/viewer/{template} (Load the given Flexible Layout in Fusion with the given template)
• GET /session/{sessionId}/{resourceName}.FeatureSource/preview (Launch a schema report preview on the given Feature Source)
• GET /session/{sessionId}/{resourceName}.LayerDefinition/preview (Launch a AJAX viewer preview of the given Layer Definition)
• GET /session/{sessionId}/{resourceName}.MapDefinition/preview (Launch a AJAX viewer preview of the given Map Definition)
• GET /session/{sessionId}/{resourceName}.SymbolDefinition/preview (Render a preview of the given Symbol Definition)
• GET /session/{sessionId}/{resourceName}.WatermarkDefinition/preview (Launch a AJAX viewer preview of the given Watermark Definition)

Improved HTML representation of the site repository

The default HTML representation of the site repository is very bare-bones and primitive.

With the power of Bootstrap 3, we've brought the HTML representation into the 21st century :)


Most of the resource options now show their results inline




Any Web Layout or Application Definition resources now expose new options for you to launch them in their respective AJAX or Fusion viewer



This is still experimental code, so standard disclaimer: use in production at your own risk.

Download

Here's the recent geonews in batch mode.

On the open source / open data front:

• Here's AmigoCloud's open source GDAL/OGR plugin for ArcGIS
• I learned about dat, an open source 'data management package' with revision control, with similarities (competing with?) with GeoGit, related, GeoGit for Python: Announcing geogit-py
• We already told you about GeoJSON over GitHub, but you can go further with GitSpatial, a spatial API for GitHub-hosted GeoJSON files
• MySQL trying to catch up PostGIS, MySQL 5.7 GIS building on Boost Geometry
• GeoA shares an entry on StoryMap JS: Tell your own story using the Open-Source Story Map tool
• Amongst recent software updates, MapTiler 0.5.3
• More editing ahead, 500,000 km2 Satellite Imagery Update for OpenStreetMap Tracing, meanwhile you can do it yourself; Drone Adventures Imagery for Tracing in OpenStreetMap: Fukushima + Lima

On the Esri front:

• 'Explorer for ArcGIS', yes, that's for this month on iOS, Explorer for ArcGIS is coming!
• Interoperability, Using OpenLayers to work with REST and OGC services from ArcGIS Server
• 2TB of new imagery, New DigitalGlobe content released in World Imagery basemap
• Updated, ArcGIS API for JavaScript Version 3.9 Released
• Becoming open, Esri ArcGIS Open Data Update

On the Google front:

• That's it, anyone in the U.S. can finally buy their own Google Glasses, but if you want one, you need to buy it on Tuesday April 15 or wait until it becomes really available to everyone, anytime, Anyone Can Buy Google Glass April 15 and directly over CNN, Google Glass available to anyone for one day only - and yes, quantities are limited
• A generic and informative article About Google Earth Imagery
• With the data layer, Build a map infographic with Google Maps & JavaScript
• Maps everywhere, USGS Maps in Google Maps Gallery
• Angkor Wat, Wander through Angkor’s thousand-year-old temples on Street View
• Another article on The obscured areas of Google Earth

Discussed over Slashdot:

• Thanks open licenses, New York Public Library Releases Over 20,000 Hi-Res Maps
• Another way to do 3D viz,  3D Display Uses Misted Water
• Taxi sharing, Taxis By Algorithm: Streamlining City Transport With Graph Theory
• Still possible in 2014, Russian GLONASS Down For 12 Hours
• Crowdsourced traffic app, In Israel, Class-Action Plaintiff Requests Waze Source Code Under GPL
• Location privacy once again, London's Public Bike Data Can Tell Everyone Where You've Been
• A map of submarine cables, Oxford Internet Institute Creates Internet "Tube" Map
• Another kind of map, Physicists Produce Antineutrino Map of the World
• Thanks OpenStreetMap once again, Racing To Contain Ebola, the map on MapBox: Mapping an entire city in a day

In the everything else category:

• We never specifically addressed the TopoJSON format, which is topological GeoJSON, related, GeoJSON for linked data, The GeoJSON-LD project
• A post that clearly demonstrates why GML was never a good solution: GML madness, hope GeoPackage will be a better one
• We never really mentioned the Internet of Things yet, worth reading a bit about this current buzz word since it has obvious geolocation ties, related, The Internet of Things forecasted to include 26 billion intelligent devices by 2020
• Another informative entry on what is geofencing, Geofencing And My Business
• An why not, Cloak – location-based anti-social app lets you avoid annoying friends and exes
• A Make article on DIY Satellites: Now and Near Future and another one named Your Own Satellite: 7 Things to Know Before You Go
• Here's why remote sensing is a profession, Earth observation data and revenue generation; the catch and guidelines and it's evolving fast, Earth observation satellite startups set to transform the EO imaging ecosystem
• Corporate privacy is dead too, monitor Saudi Arabia oil reserves from satellites, Monitoring Oil reserves from Space

In the maps category:

• GeoCurrents offers a series over Ukraine, Ukrainian Regionalism and the Federal Option, Energy Issues in the Ukrainian Crisis and Russian Envelopment? Ukraine’s Geopolitical Complexities, also related, How cartographers should map Crimea?
• In the UK? UK Air Pollution Forecast Map
• Maps is money, The interactive map of taxi trips in New York city
• And a map of companies and their worldwide presence OpenCorporates Maps by KILN
• Fiction maps, The Secrets and Clues of the Official Game of Thrones Maps and why not, The Geology of 'Game of Thrones'

Recently I had need to evaluate a Proprietary Desktop GIS (PDG for short) to document the procedure for doing a Thing for a client. To avoid any mud-slinging and name calling , I’m naming neither the PDG or the Thing, I’ll just say that the Thing is something that the PDG claims to be able to do. This is not a blog post excoriating PDGs by the way, it’s a reflection on the virtues of simplicity, good documentation, and being honest and open.

So, I download a trial version of the PDG and spend 2 hours installing and licensing it. During this time I have to consult the documentation on exactly what licensing options I wanted for a TRIAL piece of software. I also have to consult the documentation on exactly how to apply the license. No mind, I get the software installed and working and try and do the Thing. I remember from several years ago, last time I tried to do the Thing with the PDG, that it was slightly tricky, but several versions have been and gone, all of which claim to be able to do the Thing. Consequently though, I cut the PDG a bit of slack when it can’t do the Thing, and I try the work-around. Yes, that still works, though I don’t know how you’d guess that from the error messages or the documentation. It’s not ideal to need two methods of doing the Thing but hey ho. I also cut the PDG some slack when it tells me that I can only do the Thing if I adhere to some very unusual naming conventions, which will mean that, should I need to do this for real, I will have a lot of work to do renaming a bunch of stuff.

Let’s take this up a level. I don’t only need to do the Thing, but also the related Slightly More Complicated Thing (SMCT for short) too. I confess that the documentation doesn’t really say out and out that the PDG can do this, but it certainly implies it. Only, it doesn’t seem to be able to without a license for it’s rather more expensive elder brother, the Proprietary Server GIS (PSG for short). However, to explain this to the client, I will need some documentary proof. I can find blog and forum posts admitting it’s true, and for all I know there might be lots of information in the knowledge base for the PDG and PSG but you have to have a customer number to access this and because I am only evaluating the software, I haven’t purchased it yet, so I don’t have one of those.

So, I ask some questions of colleagues, and while waiting for them to get back to me, I try some work-arounds for the SMCT. Needless to say, they don’t work either.

A colleague finally gets back to me. After some incredulity that the PDG really can’t do the SMCT when everything implies that it can, said colleague, in his other role as a re-seller for the PDG rings them up and asks. “Yes, we can do that” says the first person, let me find a Thing-specialist to explain how. “No, we can’t do that” says the Thing-specialist. “Our reasons are very complicated, but here’s some obscure documentation that actually admits that we can’t do it”. We let the client know the good news.

As I said earlier, this is not a post excoriating PDG, it’s a reflection on the virtues of simplicity, good documentation, and being honest and open.

Reflection One: The whole process of installing the PDG and discovering the various methods of doing the Thing was needlessly over-complicated. This may be due to the long history of the PDG, and the enormous feature-set, but it feels like bloat. Complexity and a huge feature-set do not necessarily equate to quality, and similarly simplicity and a smaller feature-set are not a bad thing.

Reflection Two: Why hide documentation behind what’s effectively a pay-wall? Had I actually been in the market for purchasing this software, I would have given up at that point. Documentation should be freely available to everyone.

Reflection Three: We really should not have needed to get a re-seller to ring up, and speak to two different people, just to get a definitive answer on the capabilities of a piece of software. This is wrong on so many levels.

In my opinion, these points have nothing to do with the license applied to the source code of the software, or the name on the box: Don’t fall prey to Zawinski’s Law, do make your documentation comprehensive and easily accessible, and do be honest about your capabilities. I’d pay good money for that.

If your mapset contains many raster or vector layers GRASS offers a very handy feature to quickly select the layers you want to add to your current map display. In the layer manager, click Ctrl+Shift+L to open the ‘add selected map … Continue reading →

April 11, 2014
Portland, OR, USA

Regular Session and Academic Track proposals due

A reminder to all FOSS4G attendees – the proposal submission deadline for both the Academic Track and Regular Sessions is next Tuesday, April 15th. For the Regular Sessions, we strongly recommend reviewing our advice for successful proposals before submitting.

The community voting on the Regular Sessions will directly follow the deadline, April 18th to 28th.

Travel Grant Announcement

We realize that traveling to and attending a conference can be expensive, and that not everyone who uses or develops open source software has provided funding to pay their way or the means to pay for it themselves. To make sure that as many deserving people as possible can attend FOSS4G, we’re creating a travel grant program with funds to cover registration and travel costs. Watch for details coming soon.

One additional reminder: Early Bird Registration is open!

Important Conference Dates

See the full calendar for more details.

• April 15th: Academic Paper/Presentation Proposals Due
• June 15th: Early bird registration ends
• Sept 8th-9th: Workshops
• Sept 10th-12th: Main Conference
• Sept 13th: Code Sprint

 

See you in Portland,

FOSS4G PDX Local Organizing Committee

About FOSS4G

Put on by OSGeo, the annual FOSS4G conference is the premiere global gathering for people working with and creating open source geospatial software. It brings together developers, users, decision makers, and observers from a broad spectrum of organizations and fields of operation for six days of workshops, presentations, discussions, and cooperation. From this melting pot of great spatial ideas and industry flow numerous successful geospatial products, standards and protocols.

FOSS4G has been held all over the world and draws attendees from over 40 countries. Nottingham, England hosted the conference in 2013. In 2014, Portland, Oregon, USA will host FOSS4G’s tenth year.

About OSGeo

The Open Source Geospatial Foundation was founded in 2006 to support and build the highest-quality open source geospatial software. The foundation’s goal is to encourage the use and collaborative development of community-led projects, data development and education. Many projects live under the OSGeo umbrella, including FOSS4G. http://osgeo.org

About PDX OSGeo – Portland Area and Oregon OSGeo Chapter

The PDX-OSGeo chapter of OSGeo has been meeting, discussing and promoting the use of open source geospatial technology since 2009. Chapter members often organize or present on open source software at regional geospatial conferences. PDX is the airport code and like the PDX airport, the group has a wide catchment area.

Sponsors:

Silver Level Sponsors

 

Bronze Level Sponsors

 

Supporters

Media Partner

 

 

---

For more information or to keep informed from the FOSS4G Organizing Committee, follow @foss4g on Twitter, subscribe to our announcements list, or contact: foss4g2014-info@osgeo.org

Darrell Fuhriman, Chair of the FOSS4G Organizing Committee, email: darrell@garnix.org

Dear all,

we have committed in the GeoNetwork official repository a schema plugin that deals with NGMP the Nato GeoSpatial Military Profile which is available here.

As you may know, GeoNetwork has introduced in v2.8 a mechanism for supporting pluggable schemas, that is:

A schema in GeoNetwork is a directory with stylesheets, XML schema descriptions (XSDs) and other information necessary for GeoNetwork to index, view and possibly edit content from XML metadata records. 

The XML records we are dealing with are metadata following the NGMP standard, an ISO19139 application profile developed by DGIWG and NATO in order to extend the information about accessibility, releasability and classification of the data. In our use case GeoNetwork is used as a backend for harvesting prepared metadata and expose them through a CSW endpoint; it means that no editing capabilities were required.

The workplan needed to create some templates with placeholders; such templates were then processed by custom scripts that, by replacing the placeholders with information extrapolated from the real data, generated the final metadata files to be ingested in GeoNetwork .   

Editing the metadata in GeoNetwork was not needed, but creating templates by hand is extremely error prone, so as a first step we implemented the validation part, by adding the NGMP schema and writing  Schematron rules to enforce some major constraints. This first step allowed us to validate the templates and also to check the validity of the processed metadata.

1.  The ingested metadata need then to be published. Metadata dissemination is performedusing GeoNetwork itself as a viewer, so the related XSL presentation files have been developed
2. through CSW: we implemented some conversion XSL files in order to present the metadata records as base ISO19139 records (e.g. mapping some NGMP specific codelist into keywords)
3.  exporting the XML files from the GUI: we reused the XSL templates in order to offer both the NGMP record and the record "flattened" in plain ISO19139.

If you are interested in learning about how we can help you achieving your goals with our Open Source products and professional services, do not hesitate to contact us!

 The GeoSolutions team,

It’s with an enormous pleasure that we announce what we believe to be a very important step for the QGIS Portuguese speaking community, the creation of the QGIS PT users group. The QGIS PT users group arise from the notorious growth of QGIS usage  in Portugal, with the objective of become a platform for sharing […]

As with our first support story, this one comes from MassGIS, the official state agency assigned to the collection, storage, and dissemination of geographic data. When a layer has overlapping lines or polygons, we often want to control which ones are rendered on top and which ones are rendered below. The classic example is when we have a roads layer that contains overpasses that we want to appear above regular roads at ground level. MassGIS was dealing with a land-usage layer which required one type of polygon to be rendered with a solid color and other types to be rendered above with specific patterns.

The Aral Sea Example

We can simulate this problem by taking a layer that has both current and historical extents of bodies of water. In particular we’ll look at the Aral Sea, which shrunk considerably in the twentieth century. We’ll want to style the historical extents using hatching and then overlay the current lake in a plain blue style. What we don’t want is to have the historical bounds drawn over the modern lake.

You can test on your own GeoServer install with the data and SLDs in this ZIP.

SLD Rules

Our first attempt at creating an SLD to draw the two polygons in the correct order is to use two rule statements: the first will match our historical layer (where attribute type is equal to historical) and the second will match the modern layer (where the attribute type is equal to modern). We expect this to draw the historical lakes first and then the modern lakes on top:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="http://www.opengis.net/sld">
  <sld:NamedLayer>
    <sld:Name>Lakes</sld:Name>
    <UserStyle xmlns="http://www.opengis.net/sld">
      <FeatureTypeStyle>
        <Rule>
          <Name>Historical area</Name>
          ...
        </Rule>       
        <Rule>
          <Name>Modern area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </sld:NamedLayer>
</sld:StyledLayerDescriptor>

Unfortunately, this gives us the opposite effect: the historical area has been rendered above the modern area.

Since this ordering of the rules didn’t work, we can try switching them around in the SLD, putting the rule for modern lakes first and historical lakes second. If you test this in GeoServer, however, you will see that the image that we get back is not affected.

Since reordering rules in an SLD does not affect the output image, we had to provide another approach.

SLD FeatureTypeStyle

The answer to the problem is to use the rules in separate <FeatureTypeStyle> sections of our SLD document:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="http://www.opengis.net/sld">
  <sld:NamedLayer>
    <sld:Name>Lakes</sld:Name>
    <UserStyle xmlns="http://www.opengis.net/sld">
      <FeatureTypeStyle>
        <Rule>
          <Name>Historical area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
      <FeatureTypeStyle>
        <Rule>
          <Name>Modern area</Name>
          ...
        </Rule>
      </FeatureTypeStyle>
    </UserStyle>
  </sld:NamedLayer>
</sld:StyledLayerDescriptor>

Why does this work?

Our first approach did not work since rules inside a single FeatureTypeStyle are applied to features as they arrive from the data source. GeoServer was drawing the modern Aral Sea first and the historical Aral Sea second simply because that is the order in which they were stored in the shapefile.

Even if the order had been correct, it would have been dangerous to rely on it for styling since that order could change at any time.

To reliably control the rendering order, therefore, we need the multiple FeatureTypeStyle blocks. GeoServer will draw each of these independently and then merge them in the defined order as the last step.

Benjamin Trigona-Harany leads our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

The post Support story: Deterministic rendering order in SLDs appeared first on Boundless.

The United Kingdom’s railway network is split up into regional franchises, these franchises are run by private companies who bid on the work. So for example ScotRail, which runs the trains in Scotland is owned by the FIrst Group, who also run a number of other regional franchises. This can however change, when the contracts are up for bid.

Interestingly there is also a governmental holding company (Directly Operated Railways), which can take over a franchise if necessary, they currently run East Coast Trains.

For this visualization I have grouped Serco-Abellio and Abellio as Serco/Abellio.

EDIT: Like mentioned in the Scotland to the Rest of the UK, lines are drawn between stations on a route. So a direct route from Glasgow to London would be a direct line between the two terminus stations.

Inspired by Scotland’s connections to the rest of the UK.

Data:

Train lines: GTFS Data Exchange

Country outline: Natural Earth

A oficina a ser ministrada pelo prof. Gilberto Cugler sobre delimitação de bacias hidrográficas a ser realizada no evento MundoGEO#Connect Conferência e Feira de Geomática e Soluções Geoespaciais em conjunto com as 6as Jornadas da América Latina e do Caribe de gvSIG: “Inovação e desenvolvimento colaborativo: Superação e desafios” tem como objetivo mostrar a facilidade em gerar os limites de bacias e sub-bacias hidrográficas, utilizando as ferramentas incorporadas no gvSIG.

O exemplo prático será sobre uma área de aproximadamente 2000 km2 onde será delimitada a bacia do Rio Verde no município de Tapiraí estado de São Paulo/Brasil com extensão de 35 km e área de 317 km2. O processo de delimitação da bacia disponibilizará também a ordem de Strahler e outras informações que permitem fazer a análise morfométrica de uma bacia hidrográfica.

Os dados necessários para o exercício proposto estão em http://www.sigrb.com.br/capacitacao/6as_lac.php na opção 6as Jornadas da América Latina e do Caribe de gvSIG – 2014 / Detalhes conforme ilustra a figura.

Lembramos que os inscritos para a oficina deverão trazer o seu notebook com o gvSIG e os dados previamente instalados.

Para facilitar o andamento do exercício a ser desenvolvido na oficina, solicitamos padronizar a pasta de trabalho, para isto, é necessário executar o arquivo gvSIG_1.11_SIG-RB_portable_PT_BR.exe aceitando como padrão a pasta proposta (SigRibeira) e posteriormente descompactar nesta pasta os dados (Dados_6LAC.zip).

Qualquer dificuldade em baixar os arquivos ou com os dados obtidos estaremos a disposição em sigrb@sigrb.com.br ou gilbertocugler@gmail.com .

Filed under: events, gvSIG Desktop, portuguese, training

Interesting times ahead. The upcoming MySQL 5.7 promises to provide great enhancements in the spatial space. They've scrapped much of the existing GIS plumbing they have in place seen in prior 5.6 and are replacing muc of it with Boost Geometry. In addition R-Tree indexes will be available for InnoDb. Details: Why Boost.Geometry in MySQL? and Making use of Boost Geometry in MySQL. Along the roadmap (not for 5.7) they plan to have geography support as well and projections, 3D and the various output formats e.g GeoJSON currently available in PostGIS.

Just when I thought database spatial domain was getting boring. It will be interesting to see how the new MySQL Boost Geometry stacks against PostGIS GEOS /3D CGAL support. Might be time for a PostGIS/MySQL shoot-out soon.

The San Francisco Bay Area Bike Share Open Data Challenge is now underway, with entries due April 25, 2014. The idea is to use their open data on bike stations, bicycle traffic patterns, and weather to create an interesting visualization, map, or other product that adds value to the program.

Using open source mapping tools is a great way to explore the data and create winning entries for the contest. For those who are new to making maps out of open data, we’re here to help you get started. In this tutorial we’ll show you how to use QGIS, a popular mapping software product, to create a simple map out of the data. Build on this foundation to create your own contest entries and learn about data and geospatial technology along the way.

To get started, download all four data files from the contest website here. After you unzip the data you’ll see that it’s in CSV format. This is a comma delimited text file format that’s useful for spreadsheets and geospatial tables.

Installing QGIS

First, download and install QGIS. Then install the OpenLayers plugin, which simplifies adding some of the most common base layers, such as Google Maps or OSM, and makes it easier to visualize the bike station locations. You can install it by opening the Plugin Manager, selecting the Get more section and then searching for OpenLayers.

Now in the Plugins menu you should have a new entry where you can select the layers to add.

 

Adding bike share data

Add whichever basemap you like. In the following screenshots, you will see that we’ve added the Bing Road layer, which is less saturated than some of the others. A less saturated basemap helps to highlight the data that will be overlaid. You can zoom into San Francisco now or wait until the bike share data is added. To create the bike share data overlay, use the Add Delimited Text Layer button.

Add the station data file using the browse button. Use the x and y drop down selectors under Geometry definition to tell QGIS which fields have the latitude coordinates and which have the longitude coordinates. Latitude is y and longitude is x.

Your input should look like the screenshot above. Press OK. In the Coordinate Reference System Selector, type in “4326” in the Filter box and select WGS 84 in the box directly beneath it. Many — but not all — datasets in open data formats are in the WGS 84, or EPSG 4326, coordinate system.

The QGIS map should now look similar to the screenshot below. If it isn’t zoomed in properly, you can right-click the station_data layer in the Layers list and choose Zoom to Layer Extent.

Joining and analyzing bike share data

There is a lot of data in the other three tables to explore but they need to be joined to the station data first since the station data contains the geometry for displaying the data on the map, while the other tables are related to the station data geometry via its station_id field. Fields that can be used for joining are often described in files that come with the data. The README.txt file that came with this data follows this convention.

In this tutorial we’ll use the trip_data table to perform an analysis and display the results on the map. First the trip_data table needs to be added to QGIS. Click Add Delimited Text Layer again, browse to the trip_data table, and choose “No geometry” next to Geometry layer definition. Press ok. The table is added to the Layers list in QGIS. Right-click the table name in the Layers list and click Open Attribute Table. You can see the data has loaded correctly. Notice that the station_id is used in the Start Terminal and End Terminal fields.

The average duration of a trip from each station is a good first analysis. To get the average duration we have to total up the durations of each trip by Start Terminal. This could be done in a spreadsheet program, exported as a CSV file, and then added into QGIS using the steps described above for loading non-spatial tables. Alternatively, we are providing avg.py, a script created that will do the calculation within QGIS.

In the Processing menu under Options and configuration, expand Scripts and view the folder path. This is the folder path in which to save the Python script. Once the script is saved to that path, restart QGIS.

Open the Processing Toolbox by clicking Processing > Toolbox. It will appear on the right-hand side of the QGIS window. Expand Scripts, Boundless, and double-click “avg.” Fill out the dialog with the following, making sure to save the table as a CSV file in the path of your choosing.

Now you can join the output table with the station data layer in order to visualize the average duration (in seconds) of trips from each station. Double-click the station_data layer in the Layers list to bring up the Properties window. Choose Joins and click the green plus sign near the bottom of the window. Pick the table from the list that contains the average data and the field that has the station ID number. If you used the QGIS script, these will be “output_table” and “class.” The Target field is “station_id.”

Now you can look at the attribute table for the station_data to make sure the join worked properly. If it did, the fields from station_data are now in the table. (If the fields are added to the table but the cells are populated with NULL values, the wrong id field was used in the join process.)

To visualize the duration field, double click the station_data in the Layers list to open the Layer Properties and choose Style. Choose Graduated, output_table_avg for the column to style, and change the color in the color ramp as per your preference. Change the mode to Natural Breaks and press ok. (Choosing a mode that makes sense for the data and for the map is an important part of the analytical process. Here is more information on modes).

Zoom in to the denser section to see that data more clearly. Enlarge the circles by double clicking station_data, Style, click the change symbol button and change the size to 3. Click OK twice.

The trips in San Francisco appear to be shorter than the trips in Redwood City. Hopefully this tutorial on using QGIS with the Bay Area Bike Share open data provides a springboard for contest entrants. Good luck!

Interested in QGIS? Learn more at the first QGIS user group meetup in the United States on Friday, April 11!

The post Use QGIS for the Bay Area Bike Share Open Data Challenge appeared first on Boundless.

As a follow up to Scotland’s connections to outside the UK, here are the connections between Scotland and the rest of the UK. Missing is the bus network.

The train lines are drawn between stops on the route, so a direct train from London to Glasgow would be a straight line between the two terminus stations.

The real interesting thing is that there is a crosscountry train running from Glasgow to Penzance.

Data sources:

Flights – OpenFlights.org

Trains – GTFS Data Exchange

Ferries - OpenStreetmap

Land – NaturalEarth

I am convinced that most people wonder "how many ways are there to encode a polygon in GML ?" If you have never considered that before, you might be interested in reading the following lines.

To start gently, let us consider the following grey shape :




Mathematicians call it a square, which is a particularly case of a rectangle, which is itself a polygon. A simple way of describing a polygon is to list the coordinates of its corners :



Corner 0 coordinates are (0,0)
Corner 1 coordinates are (0,1)
Corner 2 coordinates are (1,1)
Corner 3 coordinates are (1,0)
And Corner 4 = Corner 0

One of the most compact way of describing that polygon in GML 3.2 is the use of the gml:Polygon element :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

We can forget the XML namespaces declaration and just concentrate on the fact that a Polygon is made of an exterior ring described by a list of positions. For those who wonder why we need to specify the "exterior", you must know that polygons may have holes in them, and those holes are called "interior rings", but we will not explore that level of complexity.

The documentation of the gml:LinearRing element shows that there are other ways of expressing the coordinates. We can isolate each corner in a separate gml:pos element :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                       http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pos>0 0</gml:pos>
            <gml:pos>0 1</gml:pos>
            <gml:pos>1 1</gml:pos>
            <gml:pos>1 0</gml:pos>
            <gml:pos>0 0</gml:pos>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

Or we can use a gml:Point inside a gml:pointProperty :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                    http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pointProperty>
                <gml:Point gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID3">
                    <gml:pos>0 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID4">
                    <gml:pos>1 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID5">
                    <gml:pos>1 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID6">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

Those who carefully look at the above snippet realize that the content of the last pointProperty is the same as the first one. So we can use xlink:href power to optimize that a bit :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:xlink="http://www.w3.org/1999/xlink"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:pointProperty>
                <gml:Point gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID3">
                    <gml:pos>0 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID4">
                    <gml:pos>1 1</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty>
                <gml:Point gml:id="ID5">
                    <gml:pos>1 0</gml:pos>
                </gml:Point>
            </gml:pointProperty>
            <gml:pointProperty xlink:href="#ID2"/>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

People nostalgic of the GML 2.1.2 era will probably want to use the now deprecated (but still valid) gml:coordinates element :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                    http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
        <!-- deprecated -->
            <gml:coordinates>0,0 0,1 1,1 1,0 0,0</gml:coordinates>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

We could play with cs (coordinate separator) and ts (tuple separator) attributes of gml:coordinates to generate alternate encoding for the coordinate list, but we will not do that. Enough with deprecated features ! Let us concentrate on modernity.

Our shape is a gml:Rectangle, isn'it ?

<?xml version="1.0"?>
<gml:Rectangle xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Rectangle>

Careful observers will notice that we have not simply substituted Polygon by Rectangle, but we have also removed the gml:id attribute. Why so ? Because a Polygon is a first citizen GML object deriving from gml:AbstractGMLType, whereas Rectangle just derives from gml:AbstractSurfacePatchType. Poor gml:Rectangle... We will come back to it later.

Until now, we have restricted the interior to be a LinearRing. But a LinearRing is a particular case of a gml:Ring :

<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                  http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

As before we can use a series of gml:pos instead of gml:posList :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:pos>0 0</gml:pos>
                    <gml:pos>0 1</gml:pos>
                    <gml:pos>1 1</gml:pos>
                    <gml:pos>1 0</gml:pos>
                    <gml:pos>0 0</gml:pos>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

But we could also use several gml:curveMember with a simple 2-point gml:LineString :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:LineString gml:id="ID2">
                    <gml:posList>0 0 0 1</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID3">
                    <gml:posList>0 1 1 1</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID4">
                    <gml:posList>1 1 1 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
            <gml:curveMember>
                <gml:LineString gml:id="ID5">
                    <gml:posList>1 0 0 0</gml:posList>
                </gml:LineString>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

Instead of a single gml:LineString, we could use a more powerful gml:Curve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                  http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

But it is a bit of a shame to use a single gml:LineStringSegment inside a gml:segments. Let us fix that :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:posList>0 0 0 1</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>0 1 1 1</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>1 1 1 0</gml:posList>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:posList>1 0 0 0</gml:posList>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

Of course we can still use gml:pointProperty to avoid repeating the same coordinate tuples :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:xlink="http://www.w3.org/1999/xlink"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:Curve gml:id="ID2">
                    <gml:segments>
                        <gml:LineStringSegment>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID3">
                                    <gml:pos>0 0</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID4">
                                    <gml:pos>0 1</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID4"/>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID5">
                                    <gml:pos>1 1</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID5"/>
                            <gml:pointProperty>
                                <gml:Point gml:id="ID6">
                                    <gml:pos>1 0</gml:pos>
                                </gml:Point>
                            </gml:pointProperty>
                        </gml:LineStringSegment>
                        <gml:LineStringSegment>
                            <gml:pointProperty xlink:href="#ID5"/>
                            <gml:pointProperty xlink:href="#ID3"/>
                        </gml:LineStringSegment>
                    </gml:segments>
                </gml:Curve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

Another child element of gml:curveMember is a gml:CompositeCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:CompositeCurve gml:id="ID2">
                    <gml:curveMember>
                        <gml:LineString gml:id="ID3">
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LineString>
                    </gml:curveMember>
                </gml:CompositeCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

But, you may have noticed that the child of a CompositeCurve is a curveMember, which is also the parent of the CompositeCurve. So we may put a CompositeCurve inside a CompositeCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:CompositeCurve gml:id="ID2">
                    <gml:curveMember>
                        <gml:CompositeCurve gml:id="ID3">
                            <gml:curveMember>
                                <gml:LineString gml:id="ID4">
                                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                                </gml:LineString>
                            </gml:curveMember>
                        </gml:CompositeCurve>
                    </gml:curveMember>
                </gml:CompositeCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

You have probably understood now that we could nest CompositeCurve as many times as wished. So we have now the answer to the initial question : there is an infinity of ways of expressing a polygon in GML 3.2 !

Another child element of gml:curveMember is a gml:OrientableCurve :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID2">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID3">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>0 1</gml:pos>
                            <gml:pos>1 1</gml:pos>
                            <gml:pos>1 0</gml:pos>
                            <gml:pos>0 0</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

But the full power of OrientableCurve is to be able to express the orientation of the curve. So let us split the ring into 2 pieces, one with positive orientation and one with negative orientation :

<?xml version="1.0"?>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:Ring>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID2">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID3">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>0 1</gml:pos>
                            <gml:pos>1 1</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
            <gml:curveMember>
                <gml:OrientableCurve gml:id="ID4" orientation="-">
                    <gml:baseCurve>
                        <gml:LineString gml:id="ID5">
                            <gml:pos>0 0</gml:pos>
                            <gml:pos>1 0</gml:pos>
                            <gml:pos>1 1</gml:pos>
                        </gml:LineString>
                    </gml:baseCurve>
                </gml:OrientableCurve>
            </gml:curveMember>
        </gml:Ring>
    </gml:exterior>
</gml:Polygon>

Enough with polygons. A polygon is just a particular case of a gml:Surface :

<?xml version="1.0"?>
<gml:Surface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:patches>
        <gml:PolygonPatch>
            <gml:exterior>
                <gml:LinearRing>
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LinearRing>
            </gml:exterior>
        </gml:PolygonPatch>
    </gml:patches>
</gml:Surface>

Instead of a gml:PolygonPatch as a child of a gml:patches, we can use the gml:Rectangle we have used before :

<?xml version="1.0"?>
<gml:Surface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:patches>
        <gml:Rectangle>
            <gml:exterior>
                <gml:LinearRing>
                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                </gml:LinearRing>
            </gml:exterior>
        </gml:Rectangle>
    </gml:patches>
</gml:Surface>

A Surface seems to be too simple. Why not using a gml:CompositeSurface ?

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                   http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:CompositeSurface>

But it looks a bit dumb to use only one gml:surfaceMember. Let us divide our square into 2 triangles :

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
    <gml:surfaceMember>
        <gml:Surface gml:id="ID3">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:CompositeSurface>

Instead of a gml:CompositeSurface, why not using a gml:MultiSurface ?

<?xml version="1.0"?>
<gml:MultiSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                      http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMember>
</gml:MultiSurface>

or maybe you prefer to use gml:surfaceMembers (with a final 's') instead of a gml:surfaceMember :

<?xml version="1.0"?>
<gml:MultiSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                       http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMembers>
        <gml:Surface gml:id="ID2">
            <gml:patches>
                <gml:PolygonPatch>
                    <gml:exterior>
                        <gml:LinearRing>
                            <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                        </gml:LinearRing>
                    </gml:exterior>
                </gml:PolygonPatch>
            </gml:patches>
        </gml:Surface>
    </gml:surfaceMembers>
</gml:MultiSurface>

Similarly to gml:CompositeCurve, we can arbitrary nest as many gml:CompositeSurface as wished :

<?xml version="1.0"?>
<gml:CompositeSurface xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                 http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:surfaceMember>
        <gml:CompositeSurface gml:id="ID2">
            <gml:surfaceMember>
                <gml:Surface gml:id="ID3">
                    <gml:patches>
                        <gml:PolygonPatch>
                            <gml:exterior>
                                <gml:LinearRing>
                                    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
                                </gml:LinearRing>
                            </gml:exterior>
                        </gml:PolygonPatch>
                    </gml:patches>
                </gml:Surface>
            </gml:surfaceMember>
        </gml:CompositeSurface>
    </gml:surfaceMember>
</gml:CompositeSurface>

So we have now two different kind of infinities ! That we could combine together. But, do not hope to have discovered more ways of expressing polygons. The cardinality of the set of natural numbers times the set of natural numbers ( N x N ) is just the cardinality of the set of natural numbers...

To conclude, we should mention that the authors of the GML specification have admitted that encoding polygons was a bit too complicated. So they have invented a "compact encoding" in the extended schemas of GML 3.3 :

<?xml version="1.0"?>
<gmlce:SimplePolygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:gmlce="http://www.opengis.net/gml/3.3/ce"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                    http://schemas.opengis.net/gml/3.2.1/gml.xsd
                    http://www.opengis.net/gml/3.3/ce
                    http://schemas.opengis.net/gml/3.3/geometryCompact.xsd"
             gml:id="ID1">
    <!-- we may, or not, close the ring -->
    <gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
</gmlce:SimplePolygon>

But our SimplePolygon is indeed a SimpleRectangle. So let us use instead :

<?xml version="1.0"?>
<gmlce:SimpleRectangle xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:gmlce="http://www.opengis.net/gml/3.3/ce"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                    http://schemas.opengis.net/gml/3.2.1/gml.xsd
                    http://www.opengis.net/gml/3.3/ce
                    http://schemas.opengis.net/gml/3.3/geometryCompact.xsd"
             gml:id="ID1">
    <!-- caution : we should NOT clause with the first vertex ! -->
    <gml:posList>0 0 0 1 1 1 1 0</gml:posList>
</gmlce:SimpleRectangle>

You can found the above 25 snippets at the following URL : http://even.rouault.free.fr/gml/
They are all valid GML 3.2 snippets that validate the XML schemas and pass the GML 3.2 Conformance Test Suite (except gml4.xsd which uses the deprecated gml:coordinates element).

Oh, final fun, as GML is XML, we can also use XML substitutable entities ...

<?xml version="1.0"?>
<!DOCTYPE points [
 <!ENTITY pt0 "0 0">
 <!ENTITY pt1 "0 1">
 <!ENTITY pt2 "1 1">
 <!ENTITY pt3 "1 0">
]>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml/3.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.opengis.net/gml/3.2
                                     http://schemas.opengis.net/gml/3.2.1/gml.xsd"
             gml:id="ID1">
    <gml:exterior>
        <gml:LinearRing>
            <gml:posList>&pt0; &pt1; &pt2; &pt3; &pt0;</gml:posList>
        </gml:LinearRing>
    </gml:exterior>
</gml:Polygon>

Those who wonder why I decided to write this article might want to have a look at the following simplified GML sample of a real-world use case where a PolygonPatch has only an interior ring (a hole), but no exterior ring... Standalone holes : interesting concept, isn't it ?

Upcoming Events

GeoRabble All Stars (April 7th)

If you are in Canberra for Locate14 conference stop by GeoRabble All Stars for a diverse lineup of speakers (and me). GeoRabble events are always a good time and registration is free. Thanks to LocationTech and Boundless for sponsoring.

Location Intelligence (May May 19-21)

If you are in Washington for Location Intelligence I will be helping out with one of the workshops and would love to see you there!

FOSS4G (Sept 8th-13th)

If you are in Portland for FOSS4G be sure to sign up now an register for workshops while there are spots open!

I will be attending with two workshops: A fun session on GeoServer Cartography and Styling for anyone who has struggled with SLD. For the developers out there I was finally brave enough to submit a GeoTools DataStore Workshop.

Past Events

Já assinalamos, em diversas ocasiões, o caráter especial (e espacial) que têm as Jornadas gvSIG de Latinoamérica e Caribe deste ano, que junto a MundoGEO#Connect constituem um ponto de encontro quase obrigatório da comunidade geo da América Latina.

Desde alguns dias atrás está disponível o programa das Jornadas, no qual podemos encontrar um amplo conjunto de apresentações, de variedade temática e geográfica, que são representativas da diversidade de áreas as quais gvSIG se aplica atualmente, desde o setor petroleiro à criminologia, passando pela gestão municipal ou de bacias hidrográficas, apresentações nas quais introduziremos as últimas novidades da tecnologia que se impulsiona desde a Associação gvSIG e os desafios que nos colocamos para o futuro. Tudo isso complementado com 3 oficinas, onde os usuários poderão aprender a manusear o gvSIG e aplicá-lo a distintos usos.

Fechando as jornadas, teremos uma mesa redonda que tratará de forma clara e direta das relações entre soberania tecnológica e software livre em Latinoamérica.

Mas, acima de tudo, as jornadas serão o ponto de encontro da Comunidade gvSIG, um espaço de colaboração e solidariedade em torno no conhecimento compartilhado.

A inscrição a todas as atividades das jornadas é totalmente gratuita e deve ser feita por meio da web do evento. No entanto, a capacidade é limitada, e não seriam as primeiras jornadas nas quais penduraríamos o cartaz de “Lotação completa”.

Filed under: community, events, gvSIG Desktop, i3Geo, portuguese, press office