Planet Georezo » Autres planets

Un Planet est un site Web dynamique qui agrÃ¨ge le plus souvent sur une seule page, le contenu de notes, d'articles ou de billets publiÃ©s sur des blogs ou sites Web afin d'accentuer leur visibilitÃ© et de faire ressortir des contenus pertinents aux multiples formats (texte, audio, vidÃ©o, Podcast). C'est un agrÃ©gateur de flux RSS. Il s'apparente Ã un portail web.
Vous pouvez lire le billet sur le blog La Minute pour plus d'informations sur les RSS !

Feeds

5013 items (0 unread) in 109 feeds

Dans la presse

Du côté des éditeurs

Toile géomatique francophone

Géomatique anglophone

Blogs GeoRezo.net

Autres planets

Planet OSGeo

Abonnez vous à cette page (RSS) !

Autres planets

Skip to page: 1 2 3 ... 12

23 January 2021
20:46
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.5.0
sur Planet OSGeo

This post is about a new update of the Semi-Automatic Classification Plugin v. 7.5.0. Following the changelog:
-added context menu in SCP dock-fixed issue with SCP dock editing of macroclasses-fixed issue with classification band set-fixed issue with autosave ROI
The main new feature is the context menu in the SCP dock that can be accessed with a right click in the ROI & Signature list.

The context menu allows for several functions that can be performed for highlighted items, such as merging or calculating the spectral signatures, or managing the tree.

Also, other issues were fixed.In the next few days I'm going to publish a new tutorial about clustering.
For any comment or question, join the Facebook group or GitHub discussions about the Semi-Automatic Classification Plugin.
22 January 2021
10:00
CARTO Blog: 3 Spatial Data Science Trends to Watch in 2021
sur Planet OSGeo

Geography is changing faster than ever before. Global warming and COVID-19 are pushing change at an unprecedented speed, modifying our environments, markets, and society. T...
21 January 2021
10:00
CARTO Blog: Identifying Areas Most Likely to Suffer Recession Post Pandemic
sur Planet OSGeo

Due to the current level of uncertainty surrounding the Covid-19 pandemic, the effects of the upcoming economic recession are nearly impossible to predict; however, history...
2:00
Lutra consulting: Overview of QGIS 3.16 LTR and QGIS 3.18 Mesh Features
sur Planet OSGeo
QGIS Mesh Layer now support DHI dfsu and HECRAS 6.0 format.

The releases of QGIS 3.16 LTR/QGIS 3.18, MDAL 0.8.0 and Crayfish 3.5.0 are planned for 19 February 2021. We are delighted to present the following improvements for the upcoming releases:
- In-memory mesh datasets with persistence
- Multi identify tool for mesh
- Virtual dataset groups for mesh layer
- 3D Mesh Layer Bug Fixes and speed optimizations
- DHI’s dfsu format support (QGIS 3.18 only)
- HECRAS 6.0 format support
If you’d like try the latest features, you can always install QGIS nightlies/master, which comes with all the latest features described in this blog post.

If you want to learn more about Mesh Layer in QGIS, read more here…
Mesh Calculator and Layer Improvements
The Virtual dataset groups for mesh layer and In-memory mesh datasets with persistence improvements greatly improves the workflows when using the Mesh Calculator in QGIS. Users can store the intermediate results into virtual layers that are recalculated on the fly (similarly to QGIS expressions for vector layers). The layers can be later persisted to any supported MDAL formats with write capabilities.

Multi identify tool for mesh feature allows to browse the temporal mesh data in more intuitive way and includes the extra information about the Mesh datasets loaded.

These features were sponsored by Artelia Group.
DHI’s dfsu format support
MDAL 0.8.0 supports loading of the external drivers. A first driver, available on Windows QGIS 3.18 only, is popular DFSU format by DHI, which is used to store MIKE 21 output results.

You can see how to configure and use QGIS to work with DFSU format on the DHI’s YouTube channel

Special thanks to the sponsor DHI this feature.
QGIS
We have added the following new features to QGIS to convert between mesh and vector/raster:
- TIN Mesh creation
- Ported most of the processing algorithms from Crayfish to QGIS core
- 3D rendering improvements
- Many Mesh Layer bugfixes
MDAL
- Support for external drivers.
- Fixed HECRAS vector datasets support
- Packaging in conda
Crayfish
- Fixed SAGA flow direction support
- Fixed FFMPEG download link
- Ported most of the processing algorithms from Crayfish to QGIS core
20 January 2021
14:24
Just van den Broecke: That Was 2020
sur Planet OSGeo
Overview of my professional life in 2020. Highlights of living and working in the Open Source Geospatial and OSGeo(.nl|.org)-world in 2020. Organized by “Theme”.

Yes, 2020 was a “special year” in pandemic and political terms. So much has been written and opinions expressed, that I don’t see a need to add to more here. Some of my activities below may make clear how I and we (OSGeo.nl community) dealt.

Screenshots of De Grote Geo Show

TL;DR. My absolute 2020-highlight was initiating and working on De Grote Geo Show (“DGGS, The Big Geo Show”), a live-streamed webshow in “De Wereld Draait Door”-style. This was/is a great team-effort by Dutch Open Source Geo/OSGeo.nl community members. Kudos to Erik, Niene, Mariëlle, Jonna, Willem, Hans and many many more (about 30+ folks)! We streamed 13 shows in 2020 with a huge range of subjects and (international) guests. And we’re still going strong with a DGGS New Year’s Show/Socializer on Sunday, Jan. 24, 2021.

Below follow 2020-highlights by theme.
The Big Geo Show
Let’s start with the absolute 2020 highlight. It became clear in March 2020 that we had to cancel or virtualize our planned (June 2020, ITC Enschede) FOSS4G-NL conference and other OSGeo.nl events. I invested some time into “webinar streaming software”: Zoom, Jitsi, Teams WebEx etc. Those did not really appeal to me for what I had in mind.

StreamYard – Backstage View

For personal streaming, I was testing OBS Studio, streaming to Twitch.tv and YouTube. I then stumbled on “Learn with Jason” . Very entertaining and deeply technical at the same time. I liked the format of having guests in the stream. That triggered me to do something similar with the Open Source Geo community in the Netherlands. Long story short: I had the idea to do a short, 1 hour webshow with various subjects and guests. Before I knew we had a Telegram group of now around 30 folks with a kernel of about 6-8 and started brainstorming. The other element which added to the success was my discovery of StreamYard.com.

Now StreamYard is a whole story by itself. In short it differs from all the well-known video-conf programs that it is a Cloud-based Broadcast Studio. Conceptually it is like making a real TV-show. There is a Stage (main screen) which can be “branded” in all sorts of creative, interactive ways: backgrounds, overlays, banners/tickers, video clips (e.g. for intro/outro or soapboxes), screen layouts, chat messages from viewers. All is controlled by one or more “hosts” (Dutch: “regisseurs”). Guests join “backstage” first and can be added to the “stage” when their item starts. And last but not least: the entire Stage can be streamed to multiple destinations at the same time like YouTube, Twitch.tv, LinkedIn etc. but also to custom RTMP servers. Viewers who missed the show could watch back later. StreamYard works completely in the browser, no installs needed. Ok, StreamYard is not Open Source, but their registration is very minimal: one only needs to provide an email adres to which a temporary login code is sent, no profile-filling etc.

So we just started, all of us not really familiar with providing online events and being first-timers in StreamYard. One learns quickest by just jumping into the deep, learning by doing, not bother about mistakes. We quickly adopted a format for a weekly one-hour show, always at the same time, Thursdays 4-5 PM. A central website tv.osgeo.nl was quickly online (with GitHub and Hugo!), so we can refer to a single, short URL.

The format of each show was basically to have 5-6 items in an hour. An “item” could be an interview with a guest, a technical presentation (or mixed interview/presentation), a column, community updates, a (hands-on) tutorial, a poem, or last but least a live-quiz (via Kahoot) where viewers can participate! After the first show (where we looked a bit like rabbits in headlights!), we quickly realized we need a presenter-host for the entire show. So all subsequent shows had one of us, well mainly Niene, being the talkshow-host. We also decided to do the show in Dutch, except with international guests, as to engage our local communities (OSGeo-NL, QGIS-NL, OpenStreetMap-NL).

Enough theory, show me the show! As said you can watch back all shows via tv.osgeo.nl or directly on the OSGeo.nl YouTube Channel. Hell, you can even binge-watch all episodes !

Many shows were organized around a theme, like 3D (ep. 3 offcourse), Heaven&Outer Space, Corona of the Sun (ep. 6 on Ascension Day). We had some great guests in the show, also international guests, to name a few: Nadieh Bremer and Christian Mayer (ep. 7 – Visualization Special), Hugo Ledoux (TU Delft on 3D), Linda van den Brink (Geonovum) and Tom Kralidis (ep 11 – on OGC API Special), Anita Graser (ep. 9 – QGIS Special), Naomi Bueno de Mesquita and Topi Tjukanov (ep 12. MapTime Special). The last show of 2020, ep. 13 Christmas Edition, was one big PubQuiz.

NewYear on “Grote Geo Eiland”

All in all we did 13 shows in 2020. And 2021? We’ll start with a Newyear Special with OSGeo-NL, QGIS-NL and OpenStreetMap-NL communities. Only the plenary first half-hour in StreamYard, then next a new platform where all can participate and mingle. Just watch and participate on sun, jan 24, 2021, 3 PM (GMT+1) via tv.osgeo.nl.
Geospatial Cloud Services
Moving into providing Geospatial Cloud Services last few years, both as a source of income and to support/strengthen underlying open source projects with which they are developed. Warning: shameless ads below.
- map5.nl is a subscription service for Dutch topographic, historical- and embellished hill-shade and arial maps I started to host in 2015. In 2020 the entire map5.nl server-infrastructure was moved from custom Ubuntu-installs to a complete Ansible/Docker-based setup.
- GeoQoS.com is a hosted GeoHealthCheck (GHC) service on a subscription basis. GHC is an uptime and QoS monitor for (OGC) web services. Customers get their own GHC instance. GeoQoS.com saves the burden of self-hosting GHC. Launch was in 2019, growing steady in 2020. Expect to work more on API and new UI for GeoHealthCheck (below) in 2021.
- Feb 2020 – launched geotoko.nl . geotoko.nl, in short GeoToko, is basically a webshop to download Dutch open geo-datasets. Here one may ask: Dutch geospatial data like Topography, Addresses and Buildings, is already open and publicly available, mainly via Kadaster-PDOK. So why bother reselling? This needs some explanation.
  
  Most Dutch Open geospatial datasets, as available from governmental institutions like Kadaster, are provided in a neutral exchange-format. In practice: GML (Application Schema). Most users are not able to directly digest complex GML in their applications (or don’t want to spend time on that). For over 10 years we run the Open Source project NLExtract to convert these datasets into formats like PostGIS and CSV that can be directly used in applications. NLExtract itself builds on Stetl, an Open Source geospatial ETL-library in Python. NLExtract/Stetl is used a lot, but still will require users to install/maintain an NLExtract/Stetl installation, download datasets, run the ETL, check results etc. That may also be a bridge too far, if e.g. all a customer needs is a one-time CSV of say, all 10 million addresses in The Netherlands. So GeoToko taps into this niche, providing ready-to-use, often enriched Dutch datasets. Pricing is reasonable, compared to other providers, plus organizations and individuals may get highly reduced pricing when they work on Open data applications like OpenStreetMap.
  
  As for development: the GeoToko webshop was developed with Django, Flask/nginx (Download management), Stripe (backend payments) and CKAN. The latter to provide a product-catalogue, sample data and metadata in general, all via GeoCatalogus.nl.
  
  GeoFabriek – Production Chain
  
  Further development concerned automating the NLExtract/Stetl ETL-processes. For this a framework called GeoFabriek, “GeoFactory”, was developed. This automates the entire chain from checking new dataset versions at Kadaster, through downloading, conversions, packing for download and updating the metadata (in GeoCatalogus.nl).
Contract Work
As my focus is more and more on providing “Geospatial Cloud Services” (see above), did not take not too much contract work in 2020, though I am always open for offerings (but may say ‘no’)!
- For Geolicious (Germany). Developed a Wegue interactive map for the German National Park Luneburger Heide. This also gave a boost to the Wegue Open Source project (see below). Was an honour to work together with the great Steve Bennett a.k.a. @stevage.
  
  Various new Widgets for Wegue were developed. To name a few: Enhanced Layer Tree, Enhanced Feature Info (see picture), Share Button, Routing, Multi-language, PDF Print, Download Features, Layout Improvements. Also introduced a “create-app” to have a starter app. We are in the process of merging back these new features into the Wegue core.
Open Source Contributions
Continuous work as a contributor. Apart from some GitLab Projects, you can find/follow me best on GitHub.
- Stetl – Geospatial ETL in Python, maintaining since 2011.
- GeoHealthCheck – Service Status and QoS Checker for OGC Web Services.
- pygeoapi – a Python server implementation of the OGC API suite of standards – joined this great project in 2019. Also in PSC.
- pygeoapi demo server – provided the (auto-)deployment stack for the pygeoapi demo server (code at GitHub). Added COVID-19 NL data provider.
- NLExtract – ETL for Dutch geospatial datasets.
- Wegue – geo-webclient framework based on Vue.js with OpenLayers started by Christian Mayer. Joined this great project in 2019.
- Heron MC – Web Mapping Client based on GeoExt and OpenLayers. Yes, old tech but still in wide use. In time hope to migrate to Wegue (see above). Migrating Heron to Wegue, see first example below.
- MapProxy – joined Program Steering Committee (PSC)
- pg_tileserv Vector Tiles directly from PostGIS!
  Contributed Dockerfile and Docker-example
More Contributions – Handy Docker Images
To support many of the Cloud services and Open Source projects, I develop and maintain handy Docker Images, also available from my DockerHub.
- docker-awstats – AWStats in Docker, oldie, but very effective webstats. Deploy multiple instances in single Docker container. Highly configurable, e.g. also for Traefik access logs.
- docker-jmeter – Apache JMeter wrapped in Docker. Over 1 million pulls!
- docker-mapfish-print – for MapFish Print version 3. MapFish Print allows printing maps as PDFs.
- docker-mapfish-print2 – for MapFish Print version 2 – This version is still used in quite some contexts, at least for Heron and KadViewer.
- docker-rclone – Docker image to perform a rclone sync based on a cron schedule, with healthchecks.io monitoring.
- docker-pgbackup – automated/scheduled PostgreSQL/PostGIS backups for all PostgreSQL-based Docker Containers in its Docker-network. I think it is nifty: just run and forget: your Postgres backups are taken care of. Inspired by: [https:]] .
New Docker images developed in 2020:
- docker-mapserver – Slim Docker Image for MapServer with Li [httpd] FastCGI.
- docker-mapproxy – MapProxy Docker Image adapted, slimmed, from the YAGA Development-Team. Awaiting PR merge.
- docker-mapproxy-mapserver – Docker Image for MapProxy service with built-in MapServer binaries accessed directly (no MapServer service).
- docker-cron – Runs Unix cron, includes docker (compose) client for running remote Docker Images.
OSGeo.nl
As chair of the board, still involved in the OSGeo Dutch Local Chapter, OSGeo.nl since its establishment in 2011.
- Jan 12 – organizer – joint OSGeo.nl and OpenStreetMap NL new-years party at Cafe Dudok in Hilversum. Our last IRL event in 2020….
No FOSS4G-NL, plans are for okt 2021, but hey, 13 episodes of De Grote Geo Show (see above)!
Conferences – Attended
- Feb 20-21 – Vue.js Amsterdam – last physically attended conf in 2020
- Sept 21-22 – GeoPython 2019 – Virtual
- Nov 19 – PostGIS Day 2020 – by crunchydata.com
Had planned: FOSSGIS-DE Freiburg (Germany), FOSS4G-EU Valmiera (Latvia), GeoPython 2020 Bilbao (Spain), FOSS4G 2020 Calgary (Canada) and OSGeo Code Sprint Athens (Greece). Was studying train-tables for all EU events…Oh well.
Talks & Workshops – Provided
Most of my slides on slideshare.net/justb4 . Below my 2020 talks.
- Sept 21-22 – Python Machine Learning & GeoPython 2020 – presented pygeoapi with Francesco Bartoli – [slides HTML]
- Dec 7-9 – GeoNode Summit 2020 – presented pygeoapi with Francesco Bartoli, Tom Kralidis, Angelos Tzotsos – [slides HTML]
- Nov 10 – GeoHealthCheck/geoqos.com workshop for RIVM (National Institute for Public Health and the Environment)
Probably some more, but cannot find back at this moment.
Resolutions 2021
- More effort into Wegue project
- Get back into Kubernetes and containerism in general
- Revive old GeoTracing projects like georambling.com
- HA projects: weather station, wildlife/bird cam, and AQ monitoring with Home Assistant
- More hiking and rambling
- Whatever comes around.
12:30
GeoTools Team: GeoTools 24.2 released
sur Planet OSGeo

The GeoTools team is pleased to share the availability of GeoTools 24.2 :geotools-24.2-bin.zipgeotools-24.2-doc.zipgeotools-24.2-userguide.zipgeotools-24.2-project.zipThis release is published to the osgeo maven repository, and is made in conjunction with GeoServer 2.18.2. This is a stable release and is a recommended upgrade for all users of the GeoTools library.We would like to thank
12:00
Fernando Quadro: PostGIS 3.1 – Suporte de função com precisão fixa
sur Planet OSGeo
Um dos novos recursos que vem no PostGIS 3.1 é o suporte à precisão fixa. Este novo recurso faz parte das novas implementações da biblioteca GEOS 3.9.

Já existem algumas funções que possuem esse novo recurso, são elas: ST_Subdivide, ST_Union, ST_SymDifference, ST_Union e ST_UnaryUnion. O recurso no ST_Union, por exemplo, deve melhorar muitos casos em que as pessoas encontram exceções topológicas. Para uma primeira visão, vamos ver como o suporte de precisão fixa afeta a função ST_Subdivide.

Vou dar uma rápida demonstração de como isso funciona cortando o estado de Massachusetts, que faz parte do arquivo de limites estaduais do censo americano. A geometria original se parece com isto:
```
SELECT geom 
FROM states 
WHERE stusps = 'MA';
```
1. Subdivisão de precisão dupla

Se utilizarmos a maneira antiga, usando o sistema de coordenadas de precisão dupla – isso resultará em 39 linhas numeradas, e será visualizado conforme a imagem abaixo:
```
SELECT f.ord, f.sd_geom
FROM states, 
  ST_Subdivide(states.geom, 300) WITH ORDINALITY AS f(sd_geom,ord) 
WHERE stusps = 'MA';
```
2. Subdivisão de precisão fixa

Agora vamos tentar isso usando uma precisão de escala fixa de 0,001 graus. Como acontece com a maioria das coisas PostGIS, as unidades são conforme o sistema de referência espacial. Neste caso, temos NAD 83 (long/lat), então estamos definindo a precisão fixa em 0,001 graus. Se fosse uma camada do Brasil, com SIRGAS 2000, SAD69, WGS 84 baseadas em coordenadas geográficas (lat/long) também utilizaríamos a mesma lógica em graus. Isso só seria diferente se a informações estivesse em UTM ao invés de Lat/Long, nesse caso ao invés de graus utilizaríamos como unidade de medida, o metro.
```
SELECT f.ord, f.sd_geom
FROM states ,
 ST_Subdivide(states.geom, 300,0.001) WITH ORDINALITY AS f(sd_geom,ord) 
WHERE stusps = 'MA';
```
O resultado é que acabamos com 10 linhas em vez de 39. Você pode perceber que as bordas são um pouco mais suaves do que a imagem anterior. Isso ocorre porque em uma precisão fixa, quando a geometria é sobreposta na grade fixa, os pontos menores do que o tamanho da grade se tornam um, resultando em menos pontos, portanto, maior extensão da área antes de atingir um limite de 300 pontos subdivididos e também uma imagem mais uniforme.

Conforme você aumenta o tamanho da grade, você obtém um resultado mais “pixelado”. Aqui aumentamos nosso tamanho de grade para 0,1 grau e acabamos com a fidelidade do PacMan. O resultado são 2 linhas de geometrias muito “pixeladas”, veja:
```
SELECT f.ord, f.sd_geom
FROM states, 
 ST_Subdivide(states.geom, 300,0.1) WITH ORDINALITY AS f(sd_geom,ord) 
WHERE stusps = 'MA';
```
Este post foi escrito originalmente por Regina Obe e foi traduzido e adaptado livremente por este blog.

Fonte: Boston GIS
1:00
GeoServer Team: GeoServer 2.18.2 Released
sur Planet OSGeo
We are pleased to announce the release of GeoServer 2.18.2 with downloads (war bin), documentation and extensions.

This release is made in conjunction with GeoTools 24.2 and GeoWebCache 1.18.2. This is a stable release recommended for production systems.

Thanks to everyone who contributed, and Alessandro Parma, Andrea Aime (GeoSolutions) for making this release.
Improvements and Fixes
This release includes a number of fixes in core and extensions:
- Improved GWC seeding scalability (also check GWC 1.18.2 release notes).
- Fixed back-links generation during WPS asynchronous requests, when a proxy base URL is used.
- Fixed a GeoFence server packaging issue.
- A number of dependent libraries have been upgraded, including the PostgreSQL and MySQL JDBC drivers, HTTP components, Guava.
Community Updates
Things get really interesting when looking at functionality provided by community modules:
- The new support for COGs based on ImageIO Ext landed in a community module, adding it adds support for COG in both the GeoTIFF reader and image mosaic. Support for harvesting COG granules is also added in the REST API.
- A deadlock in JDBCConfig has been resolved, along with issues related to high load when GeoServer has just started up.
- The WPS download “map” and “animation” processes sport improved legend support.
For more information check the 2.18.2 release notes.
About GeoServer 2.18
Additional information on GeoServer 2.18 series:
- State of GeoServer 2.18 (slides)
- GeoServer Orientation (slides|video)
- Release Notes ( 2.18.2 | 2.18.1 | 2.18.0 | 2.18-RC)
19 January 2021
0:26
Narcélio de Sá: TecnoloGEO 26 – Entrevista o Fascinante Mundo do Sensoriamento Remoto
sur Planet OSGeo
Neste podcast: No TecnoloGEO 26, PRIMEIRO episódio de entrevista do TecnoloGEO, tivemos a honra de receber o incrível Gustavo Baptista que veio nos falar um pouco sobre o quão incrível é fascinante o mundo do Sensoriamento Remoto.

E nesse episódio o Prof. Gustavo vem nos explicar como e porque criou o podcast, algumas aventuras da vida de cientista no Brasil, contou histórias de bastidores sensacionais sobre o histórico do Sensoriamento Remoto e muito mais!
Aperte o ? para começar o episódio
O TecnoloGEO é um podcast encabeçado por Murilo Cardoso e Narcélio de Sá. O Podcast é mais uma iniciativa que visa informar, instruir e, porque não, divertir pessoas que se interessam pela área de Geotecnologias.
Referências e Indicações do TecnoloGEO 26:
Sugestões de literatura:
Sugestões de vídeos:
- Geospatial Revolution
Nota de transparência: os links dos livros acima têm código de afiliado. Clicando neles, os preços não mudam, mas eu posso ganhar uma comissão da Amazon.

Fale conosco! E não esqueça de deixar o seu comentário na postagem desse episódio!

Entre em contato com o TecnoloGEO:
Equipe do TecnoloGEO:
Narcélio de SáLeonardo
João AtaídeMichelangelo
Murilo CardosoRaphael
Tiago SouzaDonatello
Luis SadeckMestre Splinter
The post TecnoloGEO 26 – Entrevista o Fascinante Mundo do Sensoriamento Remoto appeared first on Narcélio de Sá.
18 January 2021
17:19
GeoSolutions: Webinar: State of GeoServer Q1 202, 2.18 and beyond
sur Planet OSGeo
Dear Reader,

GeoServer keeps advancing with a great support from the community and the trust that organizations are putting in one of the most  popular open source tools to publish geospatial data. We, at GeoSolutions, are very fortunate to have in our team key code contributors, as well as, customers that support the advancement of GeoServer for the greater benefit of the geospatial community. Version 2.18 was released some months ago (see official blog) and the new release, 2.19 is, coming in the next month. This blog highlights the new functionalities and provides the information for our next webinar on February 3rd where you can learn more about these releases an interact with the lead GeoServer developer, Andre Aime.
Highlights of 2.18
Save time when experimenting with different configurations

A new button "Apply" allows to make changes in the admin interface, apply them and test them, leaving the window open to iterate editing and reviewing the changes. The save button closes the window. This new functionality saves time when experimenting with  various configurations.
[caption id="attachment_5733" align="aligncenter" width="995"] GeoServer UI with Apply Button[/caption]
Better scripting to support multi-band raster analysis

GeoServer relies on Jiffle, which is a scripting language, part of the JAITools project, used to create and analyze raster images. GeoServer, since 2.18, supports multi-band outputs. This will allow to e.g. analyze the changes in time on a region of interest (assuming image mosaic with time dimension) and display the differences using one single WMS request. The image bellow shows an example result where red indicates negative changes and green indicates positive changes.
[caption id="attachment_5736" align="aligncenter" width="801"] GeoServer Comparison image mosaic[/caption]
New support for Goode’s Interrupted Homolosine projection

The Goode’s interrupted Homolosine is a composite map projection used for displaying world maps and normally presented with multiple interruptions. Every cell has an equal area making it useful for presenting spatial distribution of phenomena. GeoServer, not only supports the projection, but also provides the advanced capability to handle on the fly any source and perform the data slicing. So, one can bring, e.g. OSM land masses and without any particular preparation obtain the following:
[caption id="attachment_5737" align="aligncenter" width="1024"] Land Mass Map using Goode’s interrupted Homolosine projection[/caption]
Vector Tiles Improvements
Before 2.18, when using vector tiles as a source for pre-generalized data stores, the resolution retuned was always the maximum resolution. Not any more. This release allows to properly tell the pre-generalized data store the preferred data resolution. These also speeds up the generation of MVTs from large datasets.
Improved support for Mapbox GL JS styles language
GeoServer continues to improve support for the dynamic expressions of MBStyles allowing both feature attributes and “camera” information  (e.g. zoom level) to be included.
```
{ "version": 8,
  "name": "landmarks", "layers": [
      {   "id": "Expression example",
          "type": "circle", "paint": {
              "circle-color": "#dd9933", "circle-radius":
              ["/",["get","LAND"],15],
          }
      }
  ]
}
```
[caption id="attachment_5740" align="aligncenter" width="605"] Map Render with Mapbox Styles[/caption]
Advance GeoPackage support

The GeoPackage community module has significantly advanced in terms of performance and outputs.
- Faster creation of GeoPackages when creating GeoPackages as output formats for WPS and WFS, due to the implementation of insert batching and improved selection of settings/pragma while creating the SQLite database.
- Improved metadata information in WPS outputs, providing: in-line links to metadata; OWS Contexts that can be used for request and direct access of data; and, full provenance information.
- Improved providing styles information in the GeoPackage WPS output, along with semantic annotations linking styles to data.
Highlights of 2.19

The main new capability, that I want to highlight, is the advancement of the support for "Cloud Optimized GeoTIFF (COG)" stores. In GeoServer 2.19, the community module enables easy configuration.to connect GeoServer to an AWS S3 bucket with COG images, configure the mosaic HTTP GET range read requests, and more.
[caption id="" align="aligncenter" width="502"] Configuration COG - S3 Buckets in GeoServer[/caption]
During the webinar we'll introduce you to new advancements as well, such as more GeoPackage extensions support, and Discrete Global Grid Systems support.

We cordially invite you to join the webinar on Wednesday Feb 3rd at 11:00 EDT / 16:00 GMT (check more time zones), to learn more about this release and what will be coming in 2.19 from our GeoServer Technical Lead, Andrea Aime. We are planning to do 30 minutes presentation and 30 minutes of AAA (Ask Anything to Andrea) . You can register by clicking on the button below.

Hope to see you virtually on Feb 3rd, meanwhile stay safe and keep strong!

Cordially,
Luis
12:00
Fernando Quadro: PostGIS 3.1 – Geradores de grades
sur Planet OSGeo
No último mês, foi lançada oficialmente a versão 3.1 do PostGIS, extensão espacial do PostgreSQL e com ela algumas novidades como a que iremos ver neste post, que são os geradores de grades.

Resumir dados em uma grade fixa é uma maneira comum de preparar dados para análise. As grades fixas têm algumas vantagens sobre os limites naturais e administrativos:
- Sem apelo às autoridades superiores
- Áreas de unidade iguais
- Distâncias iguais entre as células
- Bom para passar dados do domínio computacional “espacial” para um domínio “não espacial”
Idealmente, queremos ser capazes de gerar grades que tenham alguns recursos-chave:
- Ponto de origem fixo, de modo que a grade pode ser gerada novamente e não se mover
- Coordenadas de células fixas para um determinado tamanho de célula, de modo que a mesma célula possa ser referida apenas usando um endereço de célula, sem ter que materializar os limites da célula
A função ST_SquareGrid (tamanho, limites) gera uma grade com uma origem em (0, 0) no plano de coordenadas e preenche os limites dos quadrados da geometria fornecida.
```
SELECT (ST_SquareGrid(400000, ST_Transform(a.geom, 3857))).* 
FROM admin a  
WHERE name = 'Brazil';
```
Portanto, uma grade gerada usando a geometria do Brasil como referência tem esta aparência.

A função ST_HexagonGrid (tamanho, limites) funciona da mesma forma que a função de grade quadrada.

Os hexágonos são populares para alguns fins de exibição cartográfica e de modelagem. Surpreendentemente, eles também podem ser indexados usando o mesmo esquema de indexação bidimensional dos quadrados.

A grade do hexágono começa com um hexágono (0, 0) centralizado na origem, e a grade para os limites incluem todos os hexágonos que tocam os limites.

Tal como acontece com a grade quadrada, as coordenadas dos hexágonos são fixas para um tamanho de grade específico.
```
SELECT (ST_HexagonGrid(100000, ST_Transform(a.geom, 3857))).* 
FROM admin a  
WHERE name = 'Germany';
```
Aqui está uma grade hexagonal de 100 km da Alemanha:

É possível materializar resumos baseados em grade, sem realmente materializar as grades, usando as funções do gerador para criar as grades desejadas em tempo real.

Aqui está um resumo dos pontos de população, usando uma grade hexadecimal:
```
SELECT sum(pop_max) as pop_max, hexes.geom
FROM
    ST_HexagonGrid(
        4.0,
        ST_SetSRID(ST_EstimatedExtent('places', 'geom'), 4326)
    ) AS hexes
    INNER JOIN
    places AS p
    ON ST_Intersects(p.geom, hexes.geom)
GROUP BY hexes.geom;
```
Também é possível unir grades dinâmicas a ferramentas de visualização, para experiências de usuário mais dinâmicas, basta você adicionar essas visões ao seu GeoServer, por exemplo.

Este post foi escrito orignalmente por Paul Ramsey em inglês e foi traduzido e adaptado livremente por este blog.

Fonte: Crunchy Blog
10:31
Jackie Ng: Announcing: vscode-map-preview 0.5.8
sur Planet OSGeo

This minor update fixes display of spatial data that spans the international date line by turning off the flag that causes OpenLayers to auto-wrap such features
4:39
Tyler Mitchell: DIY Battery – Weekend Project – Aluminum + Bleach?
sur Planet OSGeo

The post DIY Battery – Weekend Project – Aluminum + Bleach? appeared first on spatialguru.com.
15 January 2021
11:28
Andrea Antonello: SMASH 1.6.3 is out - experimental Postgis
sur Planet OSGeo

We just released SMASH 1.6.3 on the stores. It should be available within the day.
This is basically a bugfix release, but we decided to also release one feature that will be very important in the future: postgis support.
The biggest issue with the last release is that we introduced an error trapping engine to allow the user to better send issues of the application to the developers. The problem we didn't notice for soem obscure reason is that everytime an online map tile would not be properly downloaded, this would result into a crash report. Your many email explained well the situation :-))) This version fixes this.
We also enhanced the WMS source creator (which still needs much love) with the possibility to select the image format:

The note taking workflow just got a bit simpler. You can just tap on the text and the edit field is empty if the note had never been edited. This allows for less taps, which is great out in the field.
Last but not least, we started adding PostGIS support. This will be a 2 steps effort. Step one (this one) is to add full online support. This means that you now can access the remote db view from the layers list:
Let's assume you have a test db running in your network, something like:
Then you can add a new remote db as:
you can enter the table or trigger a refresh, which will also help you in testing the connection:
you can also optionally add a where condition, if you need to load only a subset of the data.
Once the db is completed, it will stay in your list of available db datasets. Just add it as a layer to teh map using the rightmost button:
which will result in:
and on the map:
well, this looks kind of ugly. You might have seen in some previous post that SMASH supports styling via SLD specification. Well, adding style the same as we do for geopackage brings us to this:
Nice right?
Now this is a vector layer that can be selected:
The above view allows also for table data editing.
And also geometric editing is allowed:
So, why is this the first of two steps? Well, out in the field we often do not have network access, so we will need to create a solution that would allow to create a local geopackage cache, which then eventually can sync back to the remote db.
But we decided to first release the direct online postgis access, since that still has some nice usecases in situations in which the network is available. Once we have this one working stable, we will move on to the next step. So, if you are into Postgis and want to help, please test and report issues.
Enjoy!
14 January 2021
2:07
Martin Davis: Using the GEOS geosop CLI
sur Planet OSGeo
In a previous post I announced the new geosop command-line interface (CLI) for the GEOS geometry API. This post provides examples of using geosop for various tasks. (Refer to the README for more information about the various options used.)
API Testinggeosop makes testing the GEOS library much easier. Previously, testing the behaviour of the API usually required breaking out the C compiler (and updating autotools and cmake build files, and deciding whether to commit the new code for later use or throw it away, etc, etc). Now testing is often just a matter of invoking a geosop operation on appropriate data, or at worst adding a few lines of code to the exiting framework.
For example, there is a long-standing issue with how GEOS handles number formatting in WKT output. There are recent bug reports about this in GeoSwift and the Julia LibGEOS.  geosop makes it easy to run the test cases and see the less-than-desirable output:
geosop -a "POINT (654321.12 0.12)" -f wktPOINT (654321.1199999999953434 0.1200000000000000)
geosop -a "POINT (-0.4225977234 46.3406448)" -f wktPOINT (-0.4225977234000000 46.3406447999999997)
There's also an issue with precision handling. To test this we added a --precision parameter to geosop. (This is the kind of rapid development enabled by having the CLI codebase co-resident with the API.)
geosop -a "POINT (654321.126 0.126)" --precision 2 -f wktPOINT (6.5e+05 0.13)
Again we see undesirable behaviour. Using scientific notation for small numbers is unnecessary and difficult to read. And the precision value is determining the number of significant digits, not the number of decimal places as intended by the GEOS WKTWriter.setRoundingPrecision API.
These were all caused by using standard C/C++ numeric formatting, which is surprisingly limited and non-useful. After some fine work by Paul Ramsey to integrate the much better Ryu library, GEOS now has WKT output that is sensible and handles precision in a useful way.
By default, WKTWriter now nicely round-trips WKT text:
geosop -a "POINT (654321.12 0.12)" -f wktPOINT (654321.12 0.12)
geosop -a "POINT (-0.4225977234 46.3406448)" -f wktPOINT (-0.4225977234 46.3406448)
If WKTWriter.setRoundingPrecision or GEOSWKTWriter_setRoundingPrecision is called, the precision value applies to the decimal part of the number:
geosop -a "POINT (654321.1234567 0.126)" --precision 0 -f wktPOINT (654321 0)
geosop -a "POINT (654321.1234567 0.126)" --precision 2 -f wktPOINT (654321.12 0.13)
geosop -a "POINT (654321.1234567 0.126)" --precision 4 -f wktPOINT (654321.1235 0.126)
geosop -a "POINT (654321.1234567 0.126)" --precision 6 -f wktPOINT (654321.123457 0.126)
Performance TestingA key use case for geosop is to provide easy performance testing. Performance of geometric operations is highly data-dependent. It's useful to be able to run operations over different datasets and measure performance. This allows detecting performance hotspots, and confirming the efficiency of algorithms.
As a simple example of performance testing, for many years GEOS has provided optimized spatial predicates using the concept of a prepared geometry. Prepared geometry uses cached spatial indexes to dramatically improve performance for repeated spatial operations against a geometry. Here is a performance comparison of the intersects spatial predicate in its basic and prepared form.
geosop -a world.wkt -b world.wkt -t intersectsRan 59,536 intersects ops ( 179,072,088 vertices) -- 16,726,188 usec (GEOS 3.10.0dev)
geosop -a world.wkt -b world.wkt -t intersectsPrepRan 59,536 intersectsPrep ops ( 179,072,088 vertices) -- 1,278,348 usec (GEOS 3.10.0dev)
The example of testing the world countries dataset against itself is artificial, but it shows off the dramatic 16x performance boost provided by using a prepared operation.
Another interesting use is longitudinal testing of GEOS performance across different versions of the library. For instance, here's a comparison of the performance of interiorPoint between GEOS 3.7 and 3.8. The interiorPoint algorithm in GEOS 3.7 relied on overlay operations, which made it slow and sensitive to geometry invalidity. GEOS 3.8 included a major improvement which greatly improved the performance, and made the algorithm more robust. Note that the dataset being used contains some (mildly) invalid geometries towards its end, which produces an error in GEOS 3.7 if the entire dataset is run. The  --alimit 3800 option limits the number of geometries processed to avoid this issue.
GEOS 3.7geosop -a ne_10m_admin_1_states_provinces.wkb --alimit 3800 -t interiorPointRan 3,800 operations ( 1,154,703 vertices) -- 2,452,540 usec (GEOS 3.7)
GEOS 3.8geosop -a ne_10m_admin_1_states_provinces.wkb --alimit 3800 -t interiorPointRan 3,800 operations ( 1,154,703 vertices) -- 35,665 usec (GEOS 3.8)
The dramatic improvement in interiorPoint performance is clearly visible.
GeoprocessingThe raison d'etre of GEOS is to carry out geoprocessing. Most users will likely do this using one of the numerous languages, applications and databases that include GEOS. But it is still useful, convenient, and perhaps more performant to be able to process geometric data natively in GEOS.
The design of geosop enables more complex geoprocessing via chaining operations together using shell pipes. For example, here is a process which creates a Voronoi diagram of some points located in the British Isles, and then clips the Voronoi polygons to the outline of the islands. This also shows a few more capabilities of geosop:
- input can be supplied as WKT (or WKB) geometry literals on the command-line
- input can be read from the standard input (here as WKB)
- the output data is sent to the standard output, so can be directed into a file
geosop -a "MULTIPOINT ((1342 1227.5), (1312 1246.5), (1330 1270), (1316.5 1306.5), (1301 1323), (1298.5 1356), (1247.5 1288.5), (1237 1260))" -f wkb voronoi | geosop -a stdin.wkb -b uk.wkt -f wkt intersection > uk-vor.wkt
13 January 2021
2:31
Martin Davis: Introducing geosop - a CLI for GEOS
sur Planet OSGeo
The GEOS geometry API is used by many, many projects to do their heavy geometric lifting. But GEOS has always had a bit of a PR problem. Most of those projects provide a more accessible interface to perform GEOS operations. Some offer a high-level language like Python, R, or SQL (and these typically come with a REPL to make things even easier). Or there are GUIs like QGIS, or a command-line interface (CLI) like GDAL/OGR.
But you can't do much with GEOS on its own. It is a C/C++ library, and to use it you need to break out the compiler and start cutting code. It's essentially "headless". Even for GEOS developers, writing an entire C program just to try out a geometry operation on a dataset is painful, to say the least.
There is the GEOS XMLTester utility, of course. It processes carefully structured XML files, but that is hardly convenient. (And in case this brings to mind a snide comment like "2001 called and wants its file format back", XML actually works very well in JTS and GEOS as a portable and readable format for geometry tests. But I digress.)
JTS (on which GEOS is based) has the TestBuilder GUI, which works well for testing out and visualizing the results of JTS operations. JTS also has a CLI called JtsOp. Writing a GUI for GEOS would be a tall order. But a command-line interface (CLI) is much simpler to code, and has significant utility. In fact there is an interesting project called geos-cli that provides a simple CLI for GEOS. But it's ideal to have the CLI code as part of the GEOS project, since it ensures being up-to-date with the library code, and makes it easy to add operations to test new functionality.
This need has led to the development of geosop. It is a CLI for GEOS which performs a range of useful tasks:
- Run GEOS operations to confirm their semantics
- Test the behaviour of GEOS on specific geometric data
- Time the performance of operation execution
- Profile GEOS code to find hotspots
- Check memory usage characteristics of GEOS code
- Generate spatial data for use in visualization or testing
- Convert datasets between WKT and WKB
geosop has the following capabilities:
- Read WKT and WKB from files, standard input, or command-line literals
- Execute GEOS operations on the list(s) of input geometries. Binary operations are executed on every pair of input geometries (i.e. the cross join aka Cartesian product)
- Output geometry results in WKT or WKB (or text, for non-geometric results)
- Display the execution time of data input and operations
- Display a full log of the command processing
Here's a look at how it works.
geosop -h gives a list of the options and operations available:
geosop - GEOS v. 3.10.0devExecutes GEOS geometry operationsUsage: geosop [OPTION...] opName opArg
-a arg source for A geometries (WKT, WKB, file, stdin, stdin.wkb) -b arg source for B geometries (WKT, WKB, file, stdin, stdin.wkb) --alimit arg Limit number of A geometries read -c, --collect Collect input into single geometry -e, --explode Explode result -f, --format arg Output format -h, --help Print help -p, --precision arg Sets number of decimal places in WKT output -r, --repeat arg Repeat operation N times -t, --time Print execution time -v, --verbose Verbose output
Operations: area A - computes area for geometry A boundary A - computes boundary for geometry A buffer A N - cmputes the buffer of geometry A centroid A - computes centroid for geometry A contains A B - tests if geometry A contains geometry B containsPrep A B - tests if geometry A contains geometry B, using PreparedGeometry containsProperlyPrep A B - tests if geometry A properly contains geometry B using PreparedGeometry convexHull A - computes convexHull for geometry A copy A - computes copy for geometry A covers A B - tests if geometry A covers geometry B coversPrep A B - tests if geometry A covers geometry B using PreparedGeometry difference A B - computes difference of geometry A from B differenceSR A B - computes difference of geometry A from B rounding to a precision scale factor distance A B - computes distance between geometry A and B distancePrep A B - computes distance between geometry A and B using PreparedGeometry envelope A - computes envelope for geometry A interiorPoint A - computes interiorPoint for geometry A intersection A B - computes intersection of geometry A and B intersectionSR A B - computes intersection of geometry A and B intersects A B - tests if geometry A and B intersect intersectsPrep A B - tests if geometry A intersects B using PreparedGeometry isValid A - tests if geometry A is valid length A - computes length for geometry A makeValid A - computes makeValid for geometry A nearestPoints A B - computes nearest points of geometry A and B nearestPointsPrep A B - computes nearest points of geometry A and B using PreparedGeometry polygonize A - computes polygonize for geometry A reducePrecision A N - reduces precision of geometry to a precision scale factor relate A B - computes DE-9IM matrix for geometry A and B symDifference A B - computes symmetric difference of geometry A and B symDifferenceSR A B - computes symmetric difference of geometry A and B unaryUnion A - computes unaryUnion for geometry A union A B - computes union of geometry A and B unionSR A B - computes union of geometry A and B
Most GEOS operations are provided, and the list will be completed soon.
Some examples of using geosop are below.
- Compute the interior point for each country in a world polygons dataset, and output them as WKT:
geosop -a world.wkt -f wkt interiorPoint
- Determine the time required to compute buffers of distance 1 for each country in the world:
geosop -a world.wkt --time buffer 1
- Compute the union of all countries in Europe:
geosop -a europe.wkb --collect -f wkb unaryUnion

The README gives many more examples of how to use the various command-line options. In a subsequent post I'll give some demonstrations of using geosop for various tasks including GEOS testing, performance tuning, and geoprocessing.
Future WorkThere's potential to make geosop even more useful:
- GeoJSON is a popular format for use in spatial toolchains. Adding GeoJSON reading and writing would allow geosop to be more widely used for geo-processing.
- Adding SVG output would provide a way to visualize the results of GEOS operations.
- Improve support for performance testing by adding operations to generate various kinds of standard test datasets (such as point grids, polygon grids, and random point fields).
And of course, work will be ongoing to keep geosop up-to-date as new operations and functionality are added to GEOS.
12 January 2021
10:00
CARTO Blog: How to Use Spatial Data to Identify CPG Demand Hotspots
sur Planet OSGeo

In recent years, the consumption and promotion of products which fall under the category of Organic / Natural / Local has increased dramatically. These are specific types o...
11 January 2021
1:00
Lutra consulting: Mergin and PostGIS in action
sur Planet OSGeo
One of the challenges of data collection projects is consolidating all the data a central database, such as Postgres/PostGIS. Using PostGIS as a live survey layer is not usually recommended:
- Security: exposing your database to the wider internet
- Access and connectivity: internet connection is not always guaranteed for field survey projects
A more cumbersome way around this, is to convert your tables from PostGIS to a file based GIS layer (e.g. GeoPackage) and take the files with you to the field. This will create a new problem: keeping all the tables (from multiple surveyors) and the PostGIS table up-to-date.

During a survey to assess water access for villages in Limpopo province, South Africa, our friends at Kartoza have commissioned us to extend the Mergin service to support PostGIS. The Mergin service already supports file-based data synchronisation. The aim was to bridge the gap between the Mergin service and PostGIS so that the changes from Mergin immediately appear on PostGIS and vice versa.

To facilitate that, we further developed the Geodiff library to support Postgres driver. In addition, we developed mergin-db-sync tool to sync the tables from Postgres database with the Mergin service. The mergin-db-sync tool runs as a service (daemon) that keeps an eye on a particular Mergin project, and if there is a new version of the project, it will fetch the most recent changes and apply them to database tables in PostgreSQL. It works also the other way around at the same time: it looks for changes in the configured PostgreSQL schema and upload them in a new version of the Mergin project if any changes were detected. This service can be easily started on the local Intranet (where the PostgreSQL database is run) and therefore it does not need any adjustments to the firewall to allow access to the local database from public Internet.

The above diagram details how Postgres/PostGIS synchronisation works with the Mergin service via the DB-Sync tool.
- Tables 1 and 2 from the Postgres/PostGIS server are set up to work with the Mergin service
- DB-Sync tool runs on a server on a regular interval to sync with the Mergin service
- An offline version of Tables 1 and 2 are provided within the QGIS survey project on Mergin
- Several surveyors download the project and add their data mostly while offline. The data are then synced with the Mergin.
From the surveyors’ point of view, the extra set up to sync with the Postgres/PostGIS does not affect their workflow. In fact, mergin-db-sync tool acts as another client syncing data to the Mergin project, therefore it is possible to see all the changes in the project log originated from mergin-db-sync tool.

The tool is available on GitHub with a permissive open source license (MIT). At this point it supports PostgreSQL, but the mechanism is fairly generic and support for other database engines may be added in the future without great effort. All the heavy lifting is done by the Geodiff library which has been significantly enhanced during the development of mergin-db-sync tool.

To try the tool, please follow the instructions on the project’s readme on GitHub. The easiest way is to use it in a Docker container.

If you have any issues or feedback to enhance the tool, you can file a ticket on the project repo.

If you’d like to set up DB-Sync tool with your Mergin survey projects, you can contact us on info@lutraconsulting.co.uk
10 January 2021
14:33
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.4.0
sur Planet OSGeo

This post is about a new update of the Semi-Automatic Classification Plugin v. 7.4.0.
This is mainly a maintenance version with the objective to solve the multiprocessing issues related to Python installation especially in Mac OS.
In the tab Processing setting, it is now possible to enter the Python executable path (e.g. /usr/local/bin/python3) and the path to the GDAL directory containing tools such as gdal_translate and gdalwarp (e.g. /usr/bin).Of course, these paths can vary according to the operating system and the program installation.

Also, in the tab Debug it is possible to test the dependencies and check the cause of the errors in the log file.Hopefully these update should solve most of the issues related to SCP installation in Mac OS.If you are having issue related to SCP installation and multiprocessing, please report it at [https:]] , also testing the dependencies and attaching the log file as described here.
For any comment or question, join the Facebook group or GitHub discussions about the Semi-Automatic Classification Plugin.
08 January 2021
12:00
MapTiler: Mapbox GL open-source fork
sur Planet OSGeo

After Mapbox announced the closure of Mapbox GL JS, their JavaScript library for displaying maps using WebGL, the community made a collective decision to maintain and further develop the last open-source version and build a free alternative. Read the story and technical details.
MapLibre is born
In December 2020, Mapbox released the second version of their JavaScript library for publishing maps online. However, this time all the new features were overshadowed by a change in the license: previously free as a freedom, it became closed for external contributors and usage was restricted to people with active Mapbox subscriptions. One have to pay even for loading this JavaScript library.

The community reacted swiftly: forks of the latest open-source version were made almost immediately by multiple parties. In another positive development, the community came together the next day and agreed to make this a joint effort, rather than splitting energies. A video call was organized and the MapLibre coalition was formed. It includes people working for MapTiler, Elastic, StadiaMaps, Microsoft, Ceres Imaging, WhereGroup, Jawg, Stamen Design, etc.

The name, MapLibre, stands as an abbreviation for Map library restarted (or reinvented), at the same moment the word Libre refers to freedom & independence.

Members of open-source communities and companies working in the map industry agreed on basic rules, which were formalized into a guiding Memorandum. This summarized the project goals, rough roadmap, community governance details, and communication channels. Read the full text of the memorandum and join the effort: new members are welcomed!
Independent JavaScript GL mapping library
MapLibre is based on Mapbox GL JS 1.13, the most recent version available under the BSD license. The source code and ticketing system is hosted on GitHub. Together with the fork, the whole ecosystem around the library (NPM packages, binding to react, …) were also updated.

For a complete working example of the map with a style loaded from a CDN (JavaScript and HTML code sample), click on the button below (note, MapLibre is still under heavy development - this is the fourth release candidate). However, MapLibre will always be provider-independent, and you can load maps from your preferred provider or self-hosted maps.

JavaScript tutorial

Current Mapbox GL JS users can simply switch by changing a few lines of code.

If you use npm and depend on mapbox-gl directly, simply replace mapbox-gl with maplibre-gl in package.json:

You can use this library in your React app as well with help of React.useRef and React.useEffect hooks. See our live example. The most popular bindings for React and other libraries are going to be updated soon.
Native SDK for Android & iOS
As development of open-source mobile map SDKs for Android & iOS was discontinued somewhere in the middle of last year, the MapTiler team was for some time working internally on own version. This latest situation sped things up, and we are releasing the code for a broad community.

MapLibre GL Native was forked from mapbox-gl-native prior to their switch to a non-OSS license. The fork also includes Maps SDK for iOS and macOS (forked from mapbox-gl-native-ios) and Android SDK (forked from mapbox-gl-native-android). The first version is available on GitHub.

The source code which was updated to the latest version of Clang/Xcode and can be used immediately. Continuous integration and delivery was moved over to GitHub Actions from CircleCI and iOS binaries are distributed as a Swift package that contains binaries packaged using the new XCFramework format.

Android tutorial iOS tutorial

Our further proposal is to move this fork under the wings of MapLibre and further develop it together with the community. Suggestions for improvements and pull requests are welcomed!

Even though Mapbox has changed the direction in relation to open-source, we would like to express a huge appreciation to the great team of Mapbox engineers for all their effort made on the development of the numerous tools and components used in here.
06 January 2021
11:58
Andrea Antonello: Hortonmachine 0.10.0 released - get a grip on your basins size
sur Planet OSGeo

It sure is a while that I don't post about the Hortonmachine. While we work a lot on it and with it, it always kind of stays in background. Well today we decided to make a new release due to some tools that will be used in production environments. And I think one is definitely worth to mention.
Some of you might have used the netnumbering module to extract subbasins on a network. The module also accepts monitoring points to allow splitting the basin in fixed points.
For a watershed like this:
The result is something like:
Now, some models, as for example Riccardo Rigon's Geoframe, need a bit more control over the basin's size. This is why, on Riccardo's request, we added the possibility to set a desired output basins size and buffer threshold, to handle some degree of flexibility.
It has been quite some fun and recursive exercise to aggregate in the best possible way basins that are too small. We added plantuml mindmap outputs to be able to better check the way the hierarchy is getting merged. This has been really helpful, in particular to check large basins and also to check on monitoring point positions, which is where basins are meant to keep a fixed border.
Here the mindmap of the above basin, with references to areas and fixed basins:

and finally the aggregated basins mindmap assuming a desired basin size of 100000 cells (10*10 meters here) and a 20% of threshold:

and the resulting subbasins map:
The result is quite nifty, given the fact that the only basins that do not obey to the 20% buffer are either basins that are fixed and at the very top (so they can't be merged with anyone) or basin 6 which is "blocked" between 2 fixed basins, so same as before, no way to enlarge it by aggregation.
Well, you can find a release containing the tools at the usual release download site of the Hortonmachine here.
Enjoy! We surely did :-)
04 January 2021
4:00
Narcélio de Sá: TecnoloGEO #25 – Resoluções de Ano novo
sur Planet OSGeo
Neste podcast: Tchau, 2020! Feliz 2021! No TecnoloGEO 25, Narcélio de Sá, Murilo Cardoso, Luiz Sadeck, João Ataíde e Tiago Sousa apresentam suas resoluções para 2021, e iremos guardar essa lista para o nosso último episódio de 2021, uma retrospectiva do ano, onde iremos compartilhar se conseguimos, ou não, obter sucesso em nossas metas do ano.
Aperte o ? para começar o TecnoloGEO 25
O TecnoloGEO é um podcast encabeçado por Murilo Cardoso e Narcélio de Sá. O Podcast é mais uma iniciativa que visa informar, instruir e, porque não, divertir pessoas que se interessam pela área de Geotecnologias.
Referências e Indicações do TecnoloGEO 25:
Sugestões de literatura:
- Happy City: Transforming Our Lives Through Urban Design – Charles Montgomery
- A invenção da Natureza – Andrea Wulf
- A origem das espécies – Charles Darwin
- Admirável mundo novo – Aldous Leonard Huxley
- 1984 – George Orwell
- O futuro da mente – Michio Kaku
Sugestões audiovisual:
Fale conosco! E não esqueça de deixar o seu comentário na postagem desse episódio!

Entre em contato com o TecnoloGEO:
Equipe do TecnoloGEO:
Narcélio de SáLeonardo
João AtaídeMichelangelo
Murilo CardosoRaphael
Tiago SouzaDonatello
Luis SadeckMestre Splinter
The post TecnoloGEO 25 – Resoluções de Ano novo appeared first on Narcélio de Sá.
01 January 2021
18:41
Tom Kralidis: Bye Bye 2020
sur Planet OSGeo

So 2020 didn’t quite work out as expected or hoped. Still, in a year where days seemed to fold into one another, the 24 hour home office and endless virtual meetings, some successes: pygeoapi: the Python OGC API server continues to pick up steam. The project was presented, demoed and discussed at numerous events. 2020 […]
8:31
From GIS to Remote Sensing: Very Happy New Year by From GIS to Remote Sensing
sur Planet OSGeo
This post is to wish you all a very happy new year!

The new version 7 of the Semi-Automatic Classification Plugin (SCP), for QGIS 3, has been recently released. I'm really grateful to all the people who have contributed to this project, through their work translating the interface and the user manual, fixing bugs and reporting issues, and donating.
In 2021, I'll continue the development of the SCP, focusing on new features for automating and improving the processing of remote sensing images, in particular:
- improving the batch tools for automating processes;
- development of standalone APIs to use the tools through the command line or Python;
- improvement of the user interface.
And of course I'll write new tutorials about applications and case studies, such as image clustering classification of Sentinel-1, Random Forest classification, and much more.

For any comment or question, join the Facebook group about the Semi-Automatic Classification Plugin.
1:05
Stefano Costa: Peer Community in Archaeology, una peer review migliore per tutti
sur Planet OSGeo
Qualche giorno fa ho completato la mia prima peer review per Peer Community in Archaeology. Faccio peer review (o referaggio, come molti dicono in anglo-italico) da una decina d’anni. Per diversi anni sono stato editor del Journal of Open Archaeology Data e ho gestito il processo di peer review, che può essere anche molto estenuante e sempre, rigorosamente, gratuito.

Quando ho scoperto PCI Archaeology mi è parsa subito una iniziativa con grande potenzialità. La open peer review non è una novità, ma con PCI viene messo a sistema l’utilizzo sistematico dei preprint, che sono pressoché sconosciuti tra gli archeologi e ancora più tra gli archeologi italiani. Tutto il progetto Peer Community in conta al momento 11 comunità specializzate in discipline varie.

PCI Archaeology è attivo dal 2019, ha un cuore francese, è sostenuto dal CNRS e da molte università, ma anche dal Max Planck Institute, se avete bisogno di farvi convincere dal prestigio. C’è già una lista importante di riviste che ha aderito al progetto, tra cui Quaternary, PLOS One, Internet Archaeology, Open Quaternary e ovviamente Journal of Open Archaeology Data. Tra gli 80 recommenders ci sono diversi italiani, con una maggioranza sul versante preistorico e scientifico. Chi fa parte del comitato editoriale di una rivista dovrebbe dedicare un po’ di tempo a capire come funziona PCI, la via più semplice è candidarsi come reviewer e sperimentare di persona il funzionamento.
Perché la peer review aperta di PCI Archaeology è migliore per tutti?
Per gli autori, consente di far circolare la propria ricerca appena pronta per l’invio a una rivista e di sottoporla a un processo trasparente. Il preprint deve essere caricato su un server esterno affidabile, come OSF Preprints o Zenodo, perché la review ha una sua autonomia editoriale. È possibile per i reviewer rimanere anonimi ma nella maggior parte dei casi ci sarà un nome affiancato alla review che riceviamo. Il ruolo del “recommender” è abbastanza originale ed è un po’ come avere un editor su misura per ciascun articolo, che può anche essere suggerito tra quelli attivi al momento (oggi sono 80). Quando la review finisce, il preprint diventa una porzione di un “oggetto editoriale” più esteso che collega le review, la recommendation finale (che può anche essere negativa!) e le risposte degli autori alle review. Tutto è pubblico e pubblicato, archiviato e citabile, e il preprint può a questo punto essere inviato a una rivista tradizionale oppure anche citato così com’è, perché di fatto ha tutte le caratteristiche di un articolo completo: identificativo permanente, archiviazione a lungo termine, peer review.

Per i reviewer, anzitutto la trasparenza incoraggia a svolgere con maggiore attenzione la revisione, perché tutti potranno leggere i nostri commenti ? anche se scegliessimo di rimanere anonimi quella review è comunque opera nostra. Ma l’aspetto più incredibile è la possibilità di leggere gli altri reviewer! L’articolo che ho rivisto ha avuto ben 4 reviewer, è stato incoraggiante vedere che diversi punti delle nostre review erano molto simili ed è ancor più stimolante invece capire quali aspetti mi erano sfuggiti, in che modo posso migliorare la mia comprensione di un articolo e la mia attività futura di ricerca e pubblicazione.

Per i lettori, credo che una diffusione dei preprint in archeologia possa solo aiutare a far crescere la ricerca, e rendere più brillante la ricerca di buona qualità. Ovviamente i preprint sono una forma di open access, quindi tra i vantaggi c’è anche quello di scansare costosi abbonamenti che ormai nemmeno più le biblioteche specializzate riescono a mantenere. Leggere in dettaglio i commenti fatti da altri ad un articolo è corroborante, per me stimola immediatamente un approccio di curiosità, approfondimento e dibattito. Ovviamente le discussioni avvengono comunque, ma si perdono nell’etere. E comunque il fatto che un articolo venga presentato alla comunità scientifica da una persona terza è una tradizione con radici profonde, che solo la burocratizzazione dell’editoria accademica ha cancellato.

Allora, la breve lista di suggerimenti per iniziare il 2021:
- iscriversi come reviewer a PCI Archaeology
- leggere gli articoli già raccomandati!
- per la prossima pubblicazione, caricare il preprint e mandarlo a PCI Archaeology
31 December 2020
9:53
Jackie Ng: Announcing: vscode-map-preview 0.5.7
sur Planet OSGeo

This final release of anything from me for 2020 fixes our KML content scrubbing code to no longer trash KML icon styles. OpenLayers didn't support KML icons properly when this extension was first created which necessitated scrubbing said content out when previewing KML files so that at least something will render in the preview instead of nothing.
That is no longer the case, so now KML icon styles are preserved when previewing. Case in point below, we now get cutlery icons instead of the standard pin marker.

One small caveat needs to be observed: Due to content security restrictions on the HTML generated by this extension, the KML icon URLs must be [https] otherwise nothing will render.
This release also updates OpenLayers to 6.5.0 and ol-layerswitcher to 3.8.3
29 December 2020
13:34
GIScussions: Predictions need to written down
sur Planet OSGeo
Photo by Gantas Vai?iul?nas on Pexels.com
Pah to 2020!

There is little about 2020 that can be looked back on with affection but one of of my highlights has been recording over 50 episodes of the Geomob Podcast with Ed Freyfogle. I don’t think either of us really thought that it would become a “thing” but it certainly has. Plus recording a podcast is something that you sort of have to do from home so it has become a lockdown past-time.

Another little pleasure has been a regular end of week call with a group of geo friends – Denise McKenzie, Ed Parsons, Ken Field, Mark Iliffe, Jeremy Morley and Alex Wrottesley (Rollo Home and Chris Parker also join us occasionally). Often a glass of beer, wine or spirits is consumed as we wind down from our week’s travails. During 2020 Ed or I managed to record a podcast episode with each of them (Mark’s episode will go live very soon). One evening we came up with the idea of recording a Christmas Special with all of us, sort of a fusion of our Friday catchups and the podcast interviews. We recorded it one evening in November and you can listen to it here, it’s a bit chaotic but there are some good laughs and a few wise observations in there.

We looked back on our 2020’s and talked about the way mapmakers and mapviewers responded to the pandemic amongst other things, then we switched to looking forwards. I asked each of the gang to make a prediction for 2021 or something they were looking forward to. Now predictions are no use unless you can look at them a year or so later and see whether they have come true, so whilst I hope you listen to the podcast I thought I would just note the predictions in bullet point form (apologies to our contributors for my paraphrasing)
- Ken is looking forward to the ubiquity of real time data feeds and the need for real time analysis and visualisation to advance to keep up. We joked that this would give us better weather maps but actually it is much more important
- Alex expects the conversation about the ethics of geospatial to continue and hopefully lead to a better understanding of how we can and do use location data
- Ed P is looking forward to the informed use of the personal geospatial data that we all generate (that might be too liberal a paraphrase)
- I hoped that the so called GI professionals would stop pleading for more people in government and industry to understand the value of what we do, but I doubt that will happen in 2021
- Jeremy thought the government’s focus on saving money would result in more focus on location
- Denise is looking forward to the launch of the Locus Charter in January see ethics above). She predicted that Data Collaboratives would be the “big thing” ushering in new models of thematic data sharing
- Mark is looking forward to drinking in an airport (aka travel and socialising). He thinks that in 2021 people will understand what he does, I doubt it
- Ed F predicts OSM will continue to conquer the world (we recorded before the meltdown on the mailing lists or the launch of Amazon Location). He also predicted that augmented reality apps like Foursquare’s MarsBot would take off in 2021
- I think someone may have suggested that the Geospatial Commission would undergo some big change by the end of 2021
By writing this stuff down I have also predicted that we will have to have another end of year podcast next year to laugh at the foolishness of our predictions.

Happy New Year
28 December 2020
20:12
GRASS GIS: GRASS GIS Project: Wrapping up 2020
sur Planet OSGeo

A look back on 2020 An unusual year comes to an end and we nonetheless saw great success in the GRASS GIS project. Here our most relevant achievements in a nutshell: new GUI startup (GSoC student: Linda Kladivova) new releases of GRASS 7.8.3, GRASS 7.8.4 followed by GRASS 7.8.5, altogether with more than 450 fixes and improvements entirely new website, based on Hugo (co-funded by OSGeo)
27 December 2020
22:23
Stefano Costa: La villa romana di Bussana, una diretta streaming
sur Planet OSGeo

Lo scorso 12 dicembre ho organizzato e presentato un evento in diretta streaming dedicato alla villa romana di Bussana, uno dei siti archeologici più conosciuti di Sanremo.
La “locandina” dell’evento
Non mi sono mai occupato nello specifico di questo sito quindi ho pensato di coinvolgere altri colleghi, persone che hanno svolto ricerche e scavi, che hanno lavorato nel contesto paesaggistico circostante. Tutto è stato composto sotto forma di una lunga diretta di oltre tre ore e mezza, in cui ho presentato gli interventi registrati, incluse due visite virtuali, intervallate dai miei commenti e dalle risposte alle domande del pubblico, soprattutto nella seconda parte.

In questi lunghi mesi di pandemia e lockdown ho partecipato come tanti (anche se certamente non tutti, sia chiaro) a svariate videoriunioni, ho creato contenuti registrati per la diffusione da parte di istituzioni culturali e ho anche tenuto una lezione universitaria. Ma erano tutte situazioni con attori ben precisi, anche quando solo spettatori. Con l’evento dedicato alla villa di Bussana per la prima volta ho sperimentato il parlare al pubblico in diretta digitale. Parlare in pubblico è per me un fatto non quotidiano ma accade regolarmente, in particolare per conferenze e visite guidate. In questo caso la vera complicazione è stato improvvisarsi anche regista e presentatore.

La diretta streaming è stata trasmessa sulla pagina Facebook della Soprintendenza: chi mi conosce da più tempo sa che non ho più un account Facebook da molti anni e che non apprezzo nessuno dei social network proprietari che hanno così tanto peso nelle nostre vite. Tuttavia, attualmente il MiBACT segue semplicemente le abitudini comuni a tutte le pubbliche amministrazioni e istituzioni culturali, addirittura elevando a sistema la moltitudine di profili social su un nuovo portale dedicato ? CulturaItaliaOnline ? realizzato “per aggregare in un unico luogo i contenuti Social pubblicati dalle principali istituzioni culturali italiane sui propri account”. I servizi contemplati sono unicamente Facebook, Instagram e Youtube.

Quando è venuto il momento di decidere se annullare del tutto la visita guidata prevista oppure trasformarla in un evento digitale, avevo già fatto qualche prova con OBS Studio, il programma che consente di organizzare contenuti di tipi diversi e trasmettere in diretta streaming su Facebook, Youtube e molti altri servizi. OBS Studio ha molte funzionalità ed è abbastanza intuitivo, quindi permette di trasformarsi in “registi” improvvisati senza troppe difficoltà. La mia apparecchiatura domestica non era delle migliori ma tutto sommato è stata accettabile. L’inesperienza mi ha portato a sopravvalutare l’utilità della mia connessione ultraveloce, senza tenere conto della scarsa potenza del mio computer, che ha reso scarsa la qualità del video in alcuni momenti, soprattutto mentre stavo trasmettendo video registrati e contemporaneamente seguendo la diretta streaming per verificare che tutto funzionasse a dovere. La latenza di circa 30 secondi ha causato alcuni momenti di “buio” o di parlato tagliato. Non sono riuscito a trovare un modo efficace per ascoltare i contenuti registrati all’interno di OBS in modo da seguire in modo più preciso la fine delle scene preparate e il ritorno alla diretta.

Quindi la prossima volta, se possibile, dovrebbero essere due persone a occuparsi della diretta (forse nemmeno fisicamente nello stesso posto) in modo che non sia necessario sovraccaricare una singola postazione. Una scheda video dedicata avrebbe comunque migliorato di molto le prestazioni di transcodifica in diretta, e forse anche la conversione dei video registrati in formati più adatti avrebbe aiutato.

Stanno iniziando a funzionare strumenti liberi per lo streaming indipendente dalle grandi piattaforme, come owncast o Peertube 3.0. Questo è sicuramente uno sviluppo interessante, anche perché si possono comunque usare i social mass media come cassa di risonanza per la promozione senza per questo tenere il contenuto in diretta sui loro spazi e sui loro archivi capienti ma smemorati – vi sfido infatti anche a distanza di pochi giorni a trovare la registrazione se non ne conoscete l’esistenza. Per il momento potete rivedere la registrazione della diretta a questo indirizzo:

[https:]]

Il buon successo della diretta e delle visualizzazioni successive (ad oggi oltre 800) mi fa ovviamente pensare che ci sia grande bisogno di questo formato di comunicazione diretto e umano, certamente più coinvolgente di una conferenza anche se molto meno approfondito, a maggior ragione quando le conferenze si svolgono dentro un’area archeologica.
24 December 2020
10:00
Mapgears: Wrapping up 2020
sur Planet OSGeo

Happy holidays!!

With only a few days left ahead, 2020 has definitely been a year filled with challenges.

Many organizations have had to reorganize in order to continue to operate remotely, implementing new tools to maintain their activities and to allow their teams to communicate effectively.

At Mapgears, we are pleased to say that we have managed to maintain the same level of service that has made our reputation despite the distance and the current context.

And we owe it all to our excellent team!

A quick look back on 2020
In addition to offering a level of functionality and service that is up to our usual standards, our team has redoubled its efforts to continue to innovate and refine the solutions offered to our clients around the world.
evStreets: supervising public works and waste collection operations
The most recent addition to our suite of solutions, evStreets is a platform that facilitates the monitoring and supervision of public works of all kinds: waste collection, snow removal, street sweeping and more!

The evStreets platform is composed of 3 interconnected functionalities: the operations manager, the mobile application for drivers and a public application for customers and citizens.

To learn more, check out the evStreets website.
evTrails keeps growing quickly
evTrails, our recreational trails management platform, continues to grow in popularity with organizations across North America! This year, more than 5 new snowmobile and ATV organizations have decided to adopt evTrails to map their trails and communicate information to their members.

However, it is not only snowmobile and ATV organizations that joined us this year! We also had the pleasure of integrating organizations managing motocross and winter sport trails (cross-country skiing, snowshoeing, etc.) into the evTrails family.

Another big change in the product was the adoption of a new distribution model for mobile trail applications. With the new winter season well underway, some snowmobile organizations have opted for a free application model with a paid premium version that unlocks more features. A change well appreciated by members!

To learn more about evTrails, it’s this way.
The more, the merrier!
In order to support growth and continue to ensure high quality service, we are pleased to have several new members join the team this year. These new members bring a wide range of expertise, ranging from project management to mobile and backend development!

Check out our careers page for a quick look on our open positions.
Tons of new features
Through all these changes, several improvements and new features have appeared in eVouala, our flagship product from which all our solutions are derived.

Among these changes, we find a renewed interface in the administration section as well as in the tools available in the interactive mapping applications. For example, the time machine has been improved to be more intuitive and accessible to users.

It’s not just the interface that has changed: a ton of new features and tools make the platform more powerful and flexible than ever.

One example is the new query generator, which allows you to quickly classify data according to the desired parameters.

Another example would be the implementation of patterns, a new type of resource that allows more technical users to create display templates and have more control over the data that is displayed in applications.

To learn more about the many new features in eVouala and other Mapgears solutions, check out the release notes.
Holidays support schedule
The holiday season is upon us!

For this period, Mapgears will pause its normal operations from December 24th at 5:00 PM until January 4th, 2021 at 8:00 AM.

Despite this interruption in operations, a support team will be available for any service interruption or technical problem that may occur during this time.

To contact the support team, please send an email to support@mapgears.com.

That’s it for this short overview of the year 2020!

On behalf of the entire Mapgears team, we wish you happy holidays and a great year 2021!!
23 December 2020
22:21
Markus Neteler: GRASS GIS 7.8.5 released
sur Planet OSGeo
What’s new in a nutshell

As a follow-up to the previous GRASS GIS 7.8.4 we have published the new release GRASS GIS 7.8.5 with more than 80 improvements. This minor release offers new wxGUI fixes across the tree. Also the addon extension manager received various stability fixes. VRT raster map with tiled raster maps can now be properly exported and imported in the native GRASS GIS raster format.

The overview of new features in the 7.8 release series is available at new features in GRASS GIS 7.8. See also our detailed announcement with the full list of changes and bugs fixed at https://trac.osgeo.org/grass/wiki/Release/7.8.5-News.

Binaries/Installer download:
- winGRASS 7.8.5/standalone: 32bit standalone installer | 64bit standalone installer
- winGRASS 7.8.5/OSGeo4W: 32bit OSGeo4W installer | 64bit OSGeo4W installer
- Mac
- Linux
  - Debian
  - Fedora/Centos/EPEL
  - Ubuntu
  - … further binary packages for other Linux distributions will follow shortly, please check at software downloads
Source code download:
- [https:]]
- [https:]]
- To get the GRASS GIS 7.8.5 source code directly from GitHub, see here.
First time users may explore the first steps tutorial after installation.

About GRASS GIS

The Geographic Resources Analysis Support System ( [https:]] ), commonly referred to as GRASS GIS, is an Open Source Geographic Information System providing powerful raster, vector and geospatial processing capabilities. It can be used either as a stand-alone application or as backend for other software packages such as QGIS and R geostatistics or in the cloud. It is distributed freely under the terms of the GNU General Public License (GPL). GRASS GIS is a founding member of the Open Source Geospatial Foundation (OSGeo).

The GRASS Development Team, Dec 2020

The post GRASS GIS 7.8.5 released appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
20:56
Martin Davis: Fixing Buffer for fixing Polygons
sur Planet OSGeo
The OGC Simple Features specification implemented by JTS has strict rules about what constitutes a valid polygonal geometry. These include:
- Polygon rings must be simple; i.e. they may not touch or cross themselves
- MultiPolygon elements may not overlap or touch at more than a finite number of points (i.e they may not intersect along an edge)
These rules were chosen for good reason. They ensure that OGC-valid polygonal geometry is the simplest possible representation of an enclosed area. This greatly simplifies the evaluation of most operations on polygonal geometry, which leads to improved performance. JTS operations generally require input which is valid according to OGC rules. And they always (with some rare exceptions) emit result geometry which is OGC-valid.
But data in the wild is often not this well-behaved. This creates the need to "clean" or "make valid" polygonal geometry in order to carry out operations on it. Shortly after JTS was first released we discovered a useful trick: constructing a zero-width buffer via geom.buffer(0) converts an invalid polygonal geometry into a valid one. It can also be used as a simple way of converting "inverted" polygon topology (ESRI-style) into valid OGC topology. The reason this works is that the buffer algorithm inherently has to handle overlaps and self-intersections since they often occur during the generation of raw buffer offset curves. The algorithm nodes self-intersections, merges overlaps, and creates new polygons or holes if necessary.
A polygon with many invalidities: overlap, self-touch in point and line, and a "bow-tie".

The polygon fixed by using buffer(0). Note that the bow-tie portion on the right is considered to lie in the exterior of the polygon due to ring orientation, and thus is removed.
In the 20 years since the release of JTS (and its derivative GEOS) this trick has passed into the lore of open-source spatial data processing. It has become a recommended technique for fixing invalid polygonal geometry in numerous projects, such as PostGIS, Shapely, RGeo, GeoTools, R-sf and QGIS. It's also used internally in JTS, in algorithms such as DouglasPeuckerSimplifier, VWSimplifier, and Densifier which might otherwise produce invalid polygonal results.
BUT - there's a nasty little surprise lying in wait for users of buffer(0)! It doesn't always work. It turns out that the buffer algorithm has a serious flaw: in some situations involving invalid "bow-tie" topology it will discard a large part of the input geometry. This has been reported in quite a few issues (here and here in JTS, and also in GEOS and Shapely). Result of running DouglasPeuckerSimplifier on a polygon with a bow-tie. (See issue)
Close-up of the result -  clearly undesirable.
The problem occurs because the buffer algorithm computes the orientation of rings in order to build the buffer offset curve (in the case of a zero-width buffer this is just the original ring linework). Currently the Orientation.isCCW test is used to do this. This uses an efficient algorithm that determines ring orientation by checking the line segments incident on the uppermost vertex of the ring (see Wikipedia for an explanation of why this works.) For a valid ring (where the linework does not cross itself) this works perfectly. However, in a invalid self-crossing ring (sometimes called a "bow-tie" or "figure-8") a choice must be made about which lobe is assigned to be the "interior". The upper-vertex approach always picks the top lobe. If that happens to be very small, the larger part of the ring is considered "exterior" and hence is removed by buffering.
A bow-tie polygon where buffer makes the evidently wrong choice for interior.The problem occurs for non-zero buffer distances as well.
This problem has limped along for many years now, never being quite enough of a pain point to motivate the effort needed to find a fix (or to fund one!). And to be honest, the buffer code is some of the most complicated and delicate in JTS, and I was concerned about wading into it to add what seemed poised to be a fiddly correction.
But recently there has been renewed interest in providing a Make-Valid capability for JTS. This inspired me to revisit the usage of buffer(0), and think more deeply about ring orientation and its role in determining valid polygonal topology. And this led to discovering a surprisingly simple solution for the buffer issue.
The fix is to use an orientation test which takes into account the entire ring. This is provided by the Signed-Area Orientation test, implemented in Orientation.isCCWArea using the Shoelace Formula. This effectively determines orientation based on the largest area enclosed by the ring. This corresponds more closely to user expectation based on visual assessment. It also minimizes the change in area and (usually) extent.
And indeed it works:

It fixes the simplification issue nicely:

The fix consists of about 4 lines of actual code. To paraphrase a great orator, never in the history of JTS has so much benefit been given to so many by so few lines of code. Now buffer(0) can be recommended unreservedly as an effective, performant way to fix polygonal geometry. And all those helpful documentation pages can drop any qualifications they might have.
As usual, this fix will soon show up in GEOS, and from there in PostGIS and other downstream projects.
This isn't the end of the story. There are times when the effect of buffer(0) is not what is desired for fixing polygon topology. This is discussed nicely in this blog post. The ongoing research into Make Valid will explore alternatives and how to provide an API for them.
18:29
Markus Neteler: OSGeo at FOSDEM 2021 (Online) – Call for Participation for the geospatial devroom
sur Planet OSGeo

Call for Participation for FOSDEM 2021 geospatial devroom

Submission Deadline: 26.12.2020

FOSDEM is the largest free and open source developers meeting in Europe, with 8000+ participants. It normally takes place in Brussels (Belgium).

FOSDEM 2021 will be an online event. We will have a geospatial devroom again. The geospatial devroom will be on Saturday, 6 February 2021. In 2021 it will be our opportunity to bring our global community to FOSDEM.

The geospatial devroom is the place to talk about the state of the art of open, geo-related data, free and open source geospatial software and its ecosystem. This includes standards and tools, e.g. spatial databases, online mapping tools, geospatial services, used for collecting, storing, delivering, analysing, and visualizing geodata.

We are looking for you to be part of the geospatial devroom. The geospatial devroom aims to host talks about geospatial topics, GIS, and geodata projects, standards and open data.

Please submit your talk till 26. December 2020.

You find detailed information about the CfP at:
[https:]]

We hope you will submit a talk or come around at FOSDEM 2021.

See you at FOSDEM 2021

The post OSGeo at FOSDEM 2021 (Online) – Call for Participation for the geospatial devroom appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
22 December 2020
17:48
gvSIG Team: Solution to the problem when loading OSM base layer on gvSIG Mobile
sur Planet OSGeo
From some time ago, one of the requirements of the applications hosted at Play Store is that access to the different URLs has to be through [https] connections. In the latest gvSIG Mobile version, the OSM Mapnik layer that appears as base layer by default is an http connection, so it is not shown in the viewer.

The solution to show that layer is the following one:
1. Download the following file from your mobile device: [devel.gvsig.org]
2. Access to gvSIG Mobile base layers menu, and add that file.
3. Then select that “mapnik10” layer as base layer, and now if you open the viewer, the OSM layer will appear (if you have an internet connection).
Here you have a video about how to do it:
16:59
GeoTools Team: GeoTools 23.4 released
sur Planet OSGeo

The GeoTools team is pleased to share the availability of GeoTools 23.4 :geotools-23.4-bin.zipgeotools-23.4-doc.zipgeotools-23.4-userguide.zipgeotools-23.4-project.zipThis release is published to the osgeo maven repository, and is made in conjunction with GeoServer 2.17.4. This is a maintenance release and is a recommended upgrade for all users of the GeoTools library. It is expected to be
1:00
GeoServer Team: GeoServer 2.17.4 Released
sur Planet OSGeo
We are pleased to announce the release of GeoServer 2.17.4 with downloads (war bin), documentation and extensions.

This release is made in conjunction with GeoTools 23.4 and GeoWebCache 1.17.4. This is a maintenance release recommended for production systems. You are reminded that this is most likely to be the last release made on the 2.17 branch and you should consider moving to the stable 2.18 branch as soon as possible.

Thanks to everyone who contributed, and Ian Turton (Astun Technology) & Jody Garnett (GeoCat) for making this release.
Improvements and Fixes
This release includes a number of improvements. Notable improvements:
- [GEOS-9753] - Features-templating plug-in allows env parametrization on vendorOptions
- [GEOS-9765] - Add IP Address range to GeoFence UI
- [GEOS-9780] - status page shows (read-only) loopback partitions
Fixes included in this release:
- [GEOS-9689] - WFS-NG Other SRS in URN OGC format are not matched by WMS Request SRS
- [GEOS-9750] - WPS processes fail with missing CSV dependencies
- [GEOS-9754] - Not consistent array element enumeration in flat GeoJson output format
- [GEOS-9758] - CRS Panel overrides URN SRS format with EPSG:XXXX format
- [GEOS-9791] - GeoJSON bounding box axis order wrongly encoded when CRS axis order is NORTH-EAST
- [GEOS-9816] - Download links from the result of an asynchronous process will not honor the proxy base URL, if it uses HTTP header variables
For more information check the 2.17.4 release notes.
About GeoServer 2.17
Features, presentations and reference material on the 2.17 series:
- New security tab on each layer, layer group and workspace page
- Option to use date created and date modified to sort UI lists
- New resource browser extension
- New Mapbox style extension
- FOSDEM GeoServer Orientation presentation (slides video)
- Full OSM data directory for GeoServer available on GitHub
- Code of Conduct
- Release Notes (2.17.4| 2.17.3| 2.17.1| 2.17.0| 2.17-RC)
21 December 2020
20:12
GRASS GIS: GRASS GIS 7.8.5 released
sur Planet OSGeo

What’s new in a nutshell As a follow-up to the previous GRASS GIS 7.8.4 we have published the new release GRASS GIS 7.8.5 with more than 80 improvements. This minor release offers new wxGUI fixes across the tree. Also the addon extension manager received various stability fixes. VRT raster map with tiled raster maps can now be properly exported and imported in the native GRASS GIS raster format. The overview of new features in the 7.
10:00
Lutra consulting: New version of Serval QGIS plugin
sur Planet OSGeo
Raster selection tools and editing with QGIS expressions.
What’s new?
In the previous version Serval allowed for setting a constant value to a single raster cell at a time. The latest version brings in new raster cells selection tools and new ways of manipulating cells value:
- QGIS expressions and
- 3x3 low-pass filter.
Multi-bands rasters are fully supported - each band can be edited separately. Serval is meant to provide a convenient way to modify selected parts of a raster layer. It is not optimized to process entire images - use Raster Calculator for that.
Raster selection tools
In order to modify raster cells values users need to select them first with a line or polygon selection tool. The line selection tool has a configurable width and unit. Selections can also be easily imported/exported from/to a vector map layer.

Multiple selections are allowed and users can add or remove from existing selection using CTRL and SHIFT keys modifiers, respectively.

Modifying rasters with QGIS expressions
In addition to setting a constant value, new cells value might be evaluated using QGIS expressions. Users can build their expressions using cells’ row and column variables, or x and y of cell center point.

In the Serval group of the builder users will find several expression functions for:
- interpolating raster value from a mesh layer,
- averaging attribute values from vector layer features intersecting the cell,
- getting the nearest vector layer feature attribute,
- interpolating z-value from the nearest 3D linestring feature.
Interpolation on a mesh layer
With the recent QGIS additions it is very easy to create mesh layers. Users can use a mesh layer for raster cell value interpolation. For example, interpolate_from_mesh() function will identify mesh dataset value and return it as a new raster value, optionally only when the value is higher than existing cell value. It is a convenient way for finding an embankment shape on a raster DTM - see pictures below.

Interpolation on 3D linestrings
Another useful function finds the nearest point on a 3D line feature and interpolate its z-value. It could be used for fine-tuning terrain elevation from a 3D profile line.

For example, if the existing embankment crown needs to be raised by an amount at one of its ends, a user could create a profile line, adjust the vertex elevation in the Vertex Editor and use it for the interpolation.

Creating custom expression functions
In the Expression builder users can define their own functions using other types of vector and raster layers.
Applying 3x3 low-pass filter
For eliminating peak values or local cell values averaging, users can use 3x3 low-pass filter.

For more details and examples, refer to the plugin’s Manual.
4:00
Narcélio de Sá: TecnoloGEO #24 – Especial de Natal
sur Planet OSGeo
Neste podcast: Nesse episódio especial de Natal, último da primeira temporada do TecnoloGEO, nós nos reunimos ai vivo no nosso canal no Youtube para conversar sobre esse ano de 2020, falamos sobre nossas espectativas e projetos para 2021 e respondemos perguntas do nosso público.
Aperte o ? para começar o TecnoloGEO #24
O tecnoloGEO é encabeçado por Murilo Cardoso (@niilistativo) , Narcélio de Sá (@narceliodesa) e Luiz Sadeck (@sadeckgeo), o projeto tem a pretensão de ser semanal e contar sempre com convidados, que sejam relevantes ao assunto em pauta da vez, pra bater aquele bate papo descontraído e informativo sobre as Geotecnologias.
Referências e Indicações do TecnoloGEO 24:
Deixe seu comentário e participe!

Entre em contato com o TecnoloGEO:
Equipe do TecnoloGEO:
Narcélio de SáLeonardo
João AtaídeMichelangelo
Murilo CardosoRaphael
Tiago SouzaDonatello
Luis SadeckMestre Splinter
The post TecnoloGEO #24 – Especial de Natal appeared first on Narcélio de Sá.
20 December 2020
23:52
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.3.0
sur Planet OSGeo

This post is about a new update of the Semi-Automatic Classification Plugin v. 7.3.0. This version includes several bug fixes and in this version the tool for importing USGS Spectral Library was updated for the USGS Spectral Library version 7 [https:]]
The USGS Spectral Library (Kokaly, R.F., Clark, R.N., Swayze, G.A., Livo, K.E., Hoefen, T.M., Pearson, N.C., Wise, R.A., Benzel, W.M., Lowers, H.A., Driscoll, R.L., and Klein, A.J., 2017, USGS Spectral Library Version 7: U.S. Geological Survey Data Series 1035, 61 p., [https:]] ) is grouped in chapters including Minerals Soils, Coatings, Liquids, including mixtures of liquids, Organic compounds, Artificial materials, and Vegetation and other biologic materials.These spectral libraries can be imported and used for classifying remote sensing images in SCP.
Read more »
11:38
Stefano Costa: Fedora 33: recover disk space from swap partitions, and other tips for upgrading
sur Planet OSGeo
As described in detail by Andy Grover in the article Upgrading to Fedora 33: Removing Your Old Swap File on EFI Machine, Fedora 33 defaults to using a compressed-memory-based swap device using zram. There is no swap partition any more!

It’s time to reclaim that disk space. If you follow the guide in the linked article, you will successfully delete the swap partition but the disk space will remain unused.

Here’s what I did to extend my home partition by 8 GB, which I found good since it’s only 200 GB.

Fedora used LVM by default for all releases previous to 33. The commands are those that modify the “physical volume” (pvresize), the “logical volume” (lvextend) and finally the actual filesystem (resize2fs). “volgroup” and “logvol” are example labels for the LVM items, and they may be different on your system.
```
pvresize /dev/sda3
lvextend -l +100%FREE /dev/volgroup/logvol
resize2fs /dev/volgroup/logvol
```
Please make sure you have backups before doing anything that modifies disk partitions and filesystems!
nano as default editor
Fedora 33 has nano as default editor for new installs. This means you get nano instead of vi even for git commit messages. To obtain the same default if you’re upgrading from Fedora 32 or earlier, install the package nano-default-editor.

I have nothing against vi but nano is definitely easier to work with for occasional text editing in the terminal.
19 December 2020
21:21
Stefano Costa: I gasometri di Ventimiglia tra archeologia romana e industriale
sur Planet OSGeo

Qualche settimana fa, grazie all’interesse di Giovanna Rosso del Brenna per i gasometri di Ventimiglia, ho scritto un articolo per Repubblica che è stato pubblicato all’interno di una serie dedicata all’archeologia industriale della Liguria (la serie aveva tratto spunto dalle vicende legate al gasometro di Campi, vicino al viadotto autostradale sul Polcevera).

L’articolo è scritto a quattro mani con Gianpiero Martino, che è stato funzionario archeologo a Ventimiglia per diversi decenni.

Di seguito il testo integrale.

Tra i monumenti di archeologia industriale della Liguria, i gasometri di Ventimiglia sono forse quelli che oggi si trovano nel contesto più inaspettato. L’area archeologica di Nervia infatti è una delle più estese realtà di epoca romana della nostra regione, una delle floride città costiere dell’antichità con monumenti di eccezionale interesse, tra cui spicca il teatro che da pochi anni è tornato a ospitare spettacoli.

L’Officina del Gas è sorta nei primi anni del XX secolo in una zona del territorio di Ventimiglia che dalla fine dell’Ottocento fino al secondo dopoguerra è stata interessata da una serie di insediamenti industriali, infrastrutture ferroviarie e servizi urbani che ne hanno profondamente segnato la morfologia e lo sviluppo urbanistico ed edilizio.

Nel 1908 la Albintimilium romana era molto meno riconoscibile di quanto sia oggi, ma lo scavo per la costruzione dei due gasometri da parte della Tuscan Gas Company rivelò la presenza di una strada antica, registrata da Girolamo Rossi insieme ad altri ritrovamenti che però non ostacolarono in alcun modo lo sviluppo del complesso produttivo. Già allora, il profondo interro degli strati di epoca romana, che a Ventimiglia in alcuni punti raggiunge i cinque metri, faceva apparire le distinte aree romane scollegate tra loro, come monumenti isolati ed indipendenti. Fu Nino Lamboglia a iniziare i primi veri scavi stratigrafici, estesi per 1000 metri quadrati nell’angolo nord occidentale dell’Officina del gas, fino a rendere palese la sovrapposizione dell’impianto industriale ai resti delle insulae. I quartieri di abitazione civile sono articolati all’uso romano in isolati delle dimensioni di 10 per 25 m, separati da cardini e decumani con il loro ordinamento regolare. Percorrendo il cavalcavia stradale dell’Aurelia, i passanti vedono ben cinque insulae, due cardini e un decumano, con i due gasometri in secondo piano.

Paradossalmente, è stato proprio lo sfruttamento industriale dell’area di Nervia che ha consentito al Ministero dei Beni Culturali di acquisire e recuperare gli spazi che costituivano il sedime dell’antica Albintimilium, grazie al contemporaneo trasferimento delle attività dell’Italgas erede della Tuscan Gas Company, delle Ferrovie dello Stato e dell’Enel, avvenuto alla fine del XX secolo. Da allora su gran parte delle aree pubbliche, vincolate per interesse archeologico in momenti diversi già a partire dal secondo dopoguerra, ha preso il via una lunga attività di recupero e progettazione mirata a restituire l’area alla fruizione pubblica, con la costante convinzione di mantenere ed esaltare la duplice natura di questo spazio, due volte archeologico, al tempo stesso romano e industriale. Questo percorso non è ancora concluso, e ha dovuto subire varie battute di arresto compreso l’avvio di una lunga operazione di bonifica dagli idrocarburi che hanno inquinato il terreno, che attualmente ha la poco invidiabile particolarità di essere contemporaneamente un bene archeologico e un rifiuto speciale.

Oggi le strutture metalliche dei gasometri sono apprezzate soprattutto dai gabbiani e la loro dimensione archeologica, come tracce materiali di un tempo ormai passato, è evidente: il quartiere di Nervia è prevalentemente residenziale e si sta riappropriando degli spazi ex ferroviari ed ex industriali. La pista ciclabile prende il posto del parco ferroviario, valorizzando al tempo stesso i resti più significativi. L’officina del gas è quindi anche il cuore di questo tessuto di archeologia industriale, ancora in attesa di una sistemazione definitiva.

Le strutture metalliche in elevato dei gasometri, l’elemento più iconico del complesso, non si limitano a un semplice scheletro ma conservano gli elementi originari legati al funzionamento nei loro movimenti di espansione e di abbassamento della calotta, come le “selle” (carrucole) e le cremagliere nelle quali scorrevano sotto la spinta della pressione del gas. Inoltre i gasometri non sono corpi isolati: sia gli edifici ora riconvertiti a servizio dell’area archeologica, sia i forni e le strutture accessorie per la produzione del gas utilizzate nell’Officina sono state opportunamente trattate e bonificate per conservarle. Tra gli edifici, un capannone mostra ancora il pregevole disegno delle capriate metalliche Polonceau, un caratteristico esempio di struttura di copertura industriale di inizio ‘900.

Il primo progetto di musealizzazione sviluppato nel 1999 prevedeva una ibridazione ancora più stretta tra i gasometri e la città romana, con un percorso di attraversamento su due livelli che avrebbe fatto delle cisterne interrate due suggestivi ambienti espositivi dei reperti archeologici antichi, forse non a caso negli stessi anni in cui prendeva corpo la trasformazione in sede museale della Centrale Montemartini a Roma. La possibilità di riprendere l’intervento di recupero dell’intera area è arrivata lo scorso anno con un primo finanziamento del MiBACT finalizzato a “rimettere in moto” la progettazione e una fruizione almeno parziale.
4:35
Martin Davis: Randomization to the Rescue!
sur Planet OSGeo
Now that OverlayNG has landed on JTS master, it is getting attention from downstream projects interested in porting it or using it. One of the JTS ports is the Net Topology Suite (NTS) project, and it is very proactive about tracking the JTS codebase. Soon after the OverlayNG commit an NTS developer noticed an issue while running the performance tests in JTS: the InteriorPointInAreaPerfTest was now causing a StackOverflowError. This turned out to be caused by the change to GeometryPrecisionReducer to use OverlayNG with Snap-Rounding to perform robust precision reduction of polygons. Further investigation revealed that failure was occurring while querying the KdTree used in the HotPixelIndex in the SnapRoundingNoder. Moreover, in addition to the outright failure, even when queries did succeed they were taking an excessively long time for large inputs.
The reason for using a K-D tree as the search structure for HotPixels is that it supports two kinds of queries with a single structure:
- Lookup queries to find the HotPixel for a coordinate. These queries are performed while building the index incrementally. Hence a dynamic data structure like a K-D tree is required, rather than a static index such as STRtree.
- Range queries to find all HotPixels within a given extent. These queries are run after the index is loaded.
The JTS KdTree supports both of these queries more efficiently than QuadTree, which is the other dynamic index in JTS. However, K-D trees are somewhat notorious for becoming unbalanced if inserted points are coherent (i.e. contain monotonic runs in either ordinate dimension). This is exactly the situation which occurs in large, relatively smooth polygons - which is the test data used in InteriorPointInAreaPerfTest. An unbalanced tree is deeper than it would be if perfectly balanced. In extreme cases this leads to trees of very large depth relative to their size. This slows down query performance and, because the KdTree query implementation uses recursion, can also lead to stack overflow.
A perfectly balanced K-D tree, with depth = logN. In the worst case an unbalanced tree has only one node at each level (depth = N).
I considered a few alternatives to overcome this major blocker. One was to use a QuadTree, but as mentioned this would reduce performance. There are schemes to load a K-D tree in a balanced way, but they seemed complex and potentially non-performant.
It's always great when people who file issues are also able to provide code to fix the problem. And happily the NTS developer submitted a pull request with a very nice solution. He observed that while the K-D tree was being built incrementally, in fact the inserted points were all available beforehand. He proposed randomizing them before insertion, using the elegantly simple Fisher-Yates shuffle. This worked extremely well, providing a huge performance boost and eliminated the stack overflow error. Here's the relative performance times:

Num Pts Randomized In Order

10K 126 ms 341 ms

20K 172 ms 1924 ms

50K 417 ms 12.3 s

100K 1030 ms 59 s

200K 1729 ms 240 s

500K 5354 ms Overflow
Once the solution was merged into JTS, my colleague Paul Ramsey quickly ported it to GEOS, so that PostGIS and all the other downstream clients of GEOS would not encounter this issue.
It's surprising to me that this performance issue hasn't shown up in the other two JTS uses of KdTree: SnappingNoder and ConstrainedDelaunayTriangulator. More investigation required!
18 December 2020
1:00
PostGIS Development: PostGIS 3.1.0
sur Planet OSGeo

The PostGIS Team is pleased to release the release of PostGIS 3.1.0!

This version exposes the new features of GEOS 3.9 as well as numerous core performance enhancements for spatial joins, large object access, text format output and more.

Performance is a key feature of this release, with improvements to spatial joins, text outputs, large object reads, vector tile output, and a host of smaller tweaks.

The k-means clustering code has been enhanced to support weighting and higher dimensional clusters.

Geometry generators to create hexagonal and square tilings have been added, for simpler in-the-database summarization queries.

Finally, PostGIS exposes the latest enhancements in the GEOS geometry library 3.9 version. The new overlay engine (aka “OverlayNG”) provides more robust handling of difficult input geometries, using a set of new noding strategies to process geometry. For the end user, this should mean no more “topology exceptions” when using the union, difference, intersection or symmetric difference functions. PostGIS also exposes the new fixed precision overlay capability via an additional grid-size parameter on ST_Intersection and the other overlay functions.
Continue Reading by clicking title hyperlink ..
17 December 2020
10:20
gvSIG Team: Solución al problema de la carga de la capa base OSM en gvSIG Mobile
sur Planet OSGeo
Desde hace un tiempo, uno de los requerimientos de las aplicaciones alojadas en la Play Store es que los accesos a las diferentes URL sean a través de [https.] En la última versión de gvSIG Mobile, la capa mapnik de OSM que figura como capa base por defecto está como [http,] por lo que no se muestra en el visor.

La solución para que se muestre dicha capa es la siguiente:
1. Descargar el siguiente fichero desde el móvil: [devel.gvsig.org]
2. Acceder al menú de capas base de gvSIG Mobile, y añadir dicho fichero.
3. Después seleccionar esa capa “mapnik10” como capa base, y ahora si abrimos el visor nos aparecerá ya la capa de OSM (siempre que tengamos conexión a internet).
Aquí os dejamos un vídeo sobre cómo hacerlo:
10:00
CARTO Blog: Visualize Waze Traffic Data using Google BigQuery & CARTO
sur Planet OSGeo

Over 140 million monthly active drivers use Waze every day to save time and navigate roads and freeways more easily. Waze users (aka Wazers) can log accidents, potholes, sl...
10:00
CARTO Blog: Human Mobility & Transport Analysis in the Canary Islands
sur Planet OSGeo

Mobility in our cities has been experiencing big changes this year with increases in pedestrianization, bike use, and micromobility options alongside commuting shifts favor...
16 December 2020
9:00
Paul Ramsey: Waiting for PostGIS 3.1: GEOS 3.9
sur Planet OSGeo
This post originally appeared on the Crunchy Data blog.

While we talk about “PostGIS” like it’s one thing, it’s actually the collection of a number of specialized geospatial libraries, along with a bunch of code of its own.
- PostGIS provides core functionality
  - bindings to PostgreSQL, the types and indexes,
  - format reading and writing
  - basic algorithms like distance and area
  - performance tricks like caching
  - simple geometry manipulations (add a point, dump rings, etc)
  - algorithms that don’t exist in the other libraries
- Proj provides coordinate system transformations
- GDAL provides raster algorithms and format supports
- GEOS provides computational geometry algorithms
  - geometry relationships, like “intersects”, “touches” and “relate”
  - geometry operations, like “intersection”, “union”
  - basic algorithms, like “triangulate”
The algorithms in GEOS are actually a port to C++ of algoriths in the JTS Java library. The ecosystem of projects that depend on GEOS or JTS or one of the other language ports of GEOS is very large.

Overlay NG
Over the past 12 months, the geospatial team at Crunchy Data has invested heavily in JTS/GEOS development, overhauling the overlay engine that backs the Intersection, Union, Difference and *SymDifference functions in all the projects that depend on the library.

The new overlay engine, “Overlay NG”, promises to be more reliable, and hopefully also faster for most common cases.

One use of overlay code is chopping large objects up, to find the places they have in common. This query summarizes climate zones (bec) by watershed (wsa).
```
SELECT 
    Sum(ST_Area(ST_Intersection(b.geom, w.geom))) AS area_zone, 
    w.wsd_id, 
    b.zone
FROM bec b
JOIN wsa w
ON ST_Intersects(b.geom, w.geom)
WHERE w.nwwtrshdcd like '128-835500-%'
GROUP BY 2, 3
```
The new implementation for this query runs about 2 times faster than the original. Even better, when run on a larger area with more data, the origin implementation fails, it’s not possible to get a result out. The new implementation completes.

Another common use over overlay code is melting together areas that share an attribute. This query takes (almost) every watershed on Vancouver Island and melts them together.
```
SELECT ST_Union(geom)
FROM wsa
WHERE nwwtrshdcd like '920-%'
   OR nwwtrshdcd like '930-%'
```
At the start, there are 1384 watershed polygons.

At the end there is just one.

The new implementation takes about 50% longer currently, but it is more robust and less likely to fail than the original.
Fixed Precision Overlay
The way Overlay NG ensures robust results, is by falling back to more and more reliable noding approaches. “Noding” refers to how new vertices are introduced into geometries during the overlay process.
- Initially a naive “floating point” noding is used, that just uses double precision coordinates. This works most of the time, but occasionally fails when noding “almost parallel” edges.
- On failure, a “snapping” noding is used, which nudges nearby edges and nodes together within a tolerance. That works most of the time, but occasional fails.
- Finally, a “fixed precision” routing nudges all of the coordinates in both geometries into a fixed space, where edge collapses can be handled deterministically. This is the lowest performance approach, but it very very rarely occurs.
Sometimes, end users actually prefer to have their geometry forced into a fixed precision grid, and for overlay to use a fixed precision. For those users, with PostGIS 3.1 and GEOS 3.9 there are some new parameters in the intersection/union/difference functions.
The new “gridSize” parameter determines the size of the grid to snap to when generating new outputs. This can be used both to generate new geometries, and also to precision reduce existing geometries, just be unioning a geometry with an empty geometry.
Inscribed Circle
As always, there are a few random algorithmic treats in each new GEOS release. For 3.9, there is the “inscribed circle”, which finds the large circle that can be fit inside a polygon (or any other boundary).

In addition to making a nice picture, the inscribed circle functions as a measure of the “wideness” of a polygon, so it can be used for things like analyzing river polygons to determine the widest point.
9:00
Paul Ramsey: Waiting for PostGIS 3.1: Grid Generators
sur Planet OSGeo
This post originally appeared on the Crunchy Data blog.

Summarizing data against a fixed grid is a common way of preparing data for analysis. Fixed grids have some advantages over natural and administrative boundaries:
- No appeal to higher authorities
- Equal unit areas
- Equal distances between cells
- Good for passing data from the “spatial” computational realm to a “non-spatial” realm
Ideally, we want to be able to generate grids that have some key features:
- Fixed origin point, so that grid can be re-generated and not move
- Fixed cell coordinates for a given cell size, so that the same cell can be referred to just using a cell address, without having to materialize the cell bounds
ST_SquareGrid()
The ST_SquareGrid(size, bounds) function generates a grid with an origin at (0, 0) in the coordinate plane, and fills in the square bounds of the provided geometry.
```
SELECT (ST_SquareGrid(400000, ST_Transform(a.geom, 3857))).* 
FROM admin a  
WHERE name = 'Brazil';
```
So a grid generated using Brazil as the driving geometry looks like this.

ST_HexagonGrid()
The ST_HexagonGrid(size, bounds) function works much the same as the square grid function.

Hexagons are popular for some cartographic display purposes and modeling purposes. Surprisingly they can also be indexed using the same two-dimensional indexing scheme as squares.

The hexagon grid starts with a (0, 0) hexagon centered at the origin, and the gridding for a bounds includes all hexagons that touch the bounds.

As with the square gridding, the coordinates of hexes are fixed for a particular gridding size.
```
SELECT (ST_HexagonGrid(100000, ST_Transform(a.geom, 3857))).* 
FROM admin a  
WHERE name = 'Germany';
```
Here’s a 100km hexagon gridding of Germany.

Summarizing with Grids
It’s possible to materialize grid-based summaries, without actually materializing the grids, using the generator functions to create the desired grids on-the-fly.

Here’s a summary of population points, using a hex grid.
```
SELECT sum(pop_max) as pop_max, hexes.geom
FROM
    ST_HexagonGrid(
        4.0,
        ST_SetSRID(ST_EstimatedExtent('places', 'geom'), 4326)
    ) AS hexes
    INNER JOIN
    places AS p
    ON ST_Intersects(p.geom, hexes.geom)
GROUP BY hexes.geom;
```
It’s also possible to join up on-the-fly gridding to visualization tools, for very dynamic user experiences, feeding these dynamically generated grids out to the end user via pg_tileserv.
9:00
Paul Ramsey: Waiting for PostGIS 3.1: Performance
sur Planet OSGeo
This post originally appeared on the Crunchy Data blog.

Open source developers sometimes have a hard time figuring out what feature to focus on, in order to generate the maximum value for end users. As a result, they will often default to performance.

Performance is the one feature that every user approves of. The software will keep on doing all the same cool stuff, only faster.

For PostGIS 3.1, there have been a number of performance improvements that, taken together, might add up to a substantial performance gain for your workloads.
Large Geometry Caching
Spatial joins have been slowed down by the overhead of large geometry access for a very long time.
```
SELECT A.*, B.*
FROM A
JOIN B
ON ST_Intersects(A.geom, B.geom)
```
PostgreSQL will plan and execute spatial joins like this using a “nested loop join”, which means iterating through one side of the join, and testing the join condition. This results in executions that look like:
- ST_Intersects(A.geom(1), B.geom(1))
- ST_Intersects(A.geom(1), B.geom(2))
- ST_Intersects(A.geom(1), B.geom(3))
So one side of the test repeats over and over.

Caching that side and avoiding re-reading the large object for each iteration of the loop makes a huge difference to performance. We have seen 20 times speed-ups in common spatial join workloads (see below).

The fixes are quite technical, but if you are interested we have a detailed write-up available.
Header-only Geometry Reads
The on-disk format for geometry includes a short header that includes information about the geometry bounds, the spatial reference system and dimensionality. That means it’s possible for some functions to return an answer after only reading a few bytes of the header, rather than the whole object.

However, not every function that could do a fast read, did do a fast read. That is now fixed.
Faster Text Generation
It’s pretty common for web applications and others to generate text formats inside the database, and the code for doing so was not optimized. Generating “well-known text” (WKT), GeoJSON, and KML output all now use a faster path and avoid unnecessary copying.

PostGIS also now uses the same number-to-text code as PostgreSQL, which has been shown to be faster, and also allows us to expose a little more control over precision to end users.
How Much Faster?
For the specific use case of spatially joining, here is my favourite test case:
- 1:10M Country Boundaries
- 1:10M Populated Places
Load the data into both versions.
```
shp2pgsql -D -s 4326 -I ne_10m_admin_0_countries admin | psql postgis30
shp2pgsql -D -s 4326 -I ne_10m_populated_places places | psql postgis30
```
Run a spatial join that finds the sum of populated places in each country.
```
EXPLAIN ANALYZE
SELECT Sum(p.pop_max) as pop_max, a.name
FROM admin a
JOIN places p
ON ST_Intersects(a.geom, p.geom)
GROUP BY a.name
```
Average time over 5 runs:
- PostGIS 3.0 = 23.4s
- PostGIS 3.1 = 0.9s
This test is somewhat of a “worst case”, in that there are lots of very large countries in the admin data, but it gives an idea of the kind of speed-ups that are available for spatial joins against collections that include larger (250+ coordinates) geometries.
15 December 2020
16:35
gvSIG Team: Taller SIG aplicado a gestión municipal
sur Planet OSGeo

En las pasadas Jornadas GeoLIBERO se realizó un taller de SIG aplicado a gestión municipal, cuya grabación ya está disponible.

En el propio vídeo se indica de dónde descargar los datos y software necesario para seguir y replicar los distintos ejercicios que se realizan durante el taller.
14 December 2020
1:00
Lutra consulting: Mergin and PostGIS in action
sur Planet OSGeo
One of the challenges of data collection projects is consolidating all the data a central database, such as Postgres/PostGIS. Using PostGIS as a live survey layer is not usually recommended:
- Security: exposing your database to the wider internet
- Access and connectivity: internet connection is not always guaranteed for a field survey projects
A more cumbersome way around this, is to convert your tables from PostGIS to a file based GIS layer (e.g. Geopackage) and take the files with you to the field. This will create a new problem: keeping all the tables (from multiple surveyors) and the PostGIS table up-to-date.

During an XXX survey, our friends at Kartoz have commissioned us to extend the Mergin service to support PostGIS. The Mergin service already supports file-based data synchronisation. The aim was to bridge the gap between the Mergin service and PostGIS so that the changes from Mergin immediately appear on PostGIS and vice versa.

To facilitate that, we further developed the Geodiff library to support Postgres driver. In addition, we developed a tool to sync the tables from Postgres database with the Mergin service.

The above diagram, details how Postgres/PostGIS synchronisation works with the Mergin service via the DB-Sync tool.
- Tables 1 and 2 from the Postgres/PostGIS server are set up to work with the Mergin service
- DB-Sync tool runs on the server (same server as the Postgres) on a regular interval to sync with the Mergin service
- An offline version of Tables 1 and 2 are provided within the QGIS survey project on Mergin
- Several surveyors download the project and add their data mostly while offline. The data are then synced with the Mergin.
1:00
PostGIS Development: PostGIS 3.1.0rc1
sur Planet OSGeo
The PostGIS Team is pleased to release the release candidate of the upcoming PostGIS 3.1.0 release. This version is exposes some of the new performance and feature enhancements in GEOS 3.9 as well as numerous speed enhancements not requiring newer GEOS.

Best served with:
Continue Reading by clicking title hyperlink ..
13 December 2020
21:49
Markus Neteler: MapScaping podcast: GRASS GIS probably doesn’t get the attention it deserves
sur Planet OSGeo

In episode 86 of MapScaping podcast, Markus Neteler talks about the functionality offered (the topological vector engine, 2D and 3D raster analysis, image processing and available programming interfaces), and whom GRASS GIS is for.

Markus is the cofounder of mundialis, a Bonn based business. He is also the Chairman of the GRASS GIS Project Steering Committee.

Enjoy the podcast and the transcript!

The post MapScaping podcast: GRASS GIS probably doesn’t get the attention it deserves appeared first on GFOSS Blog | GRASS GIS and OSGeo News.
13:56
Free and Open Source GIS Ramblings: Spatial data exploration with linked plots
sur Planet OSGeo
In the previous post, we explored how hvPlot and Datashader can help us to visualize large CSVs with point data in interactive map plots. Of course, the spatial distribution of points usually only shows us one part of the whole picture. Today, we’ll therefore look into how to explore other data attributes by linking other (non-spatial) plots to the map.

This functionality, referred to as “linked brushing” or “crossfiltering” is under active development and the following experiment was prompted by a recent thread on Twitter launched by @plotlygraphs announcement of HoloViews 1.14:

Dash HoloViews was just released as part of @HoloViews version 1.14!

$ ??? ??????? ?????????==1.14

Automatically link selections across multiple plots (crossfiltering)
Display #BigData using #Datashader @jonmease's post: [https:]]

— plotly (@plotlygraphs) December 3, 2020

Turns out these features are not limited to plotly but can also be used with Bokeh and hvPlot:

It'll even work for hvPlot output. Would definitely be interested to see how it interacts with the geometries you usually work with.

— Philipp Rudiger (@PhilippJFR) December 4, 2020

Like in the previous post, this demo uses a Pandas DataFrame with 12 million rows (and HoloViews 1.13.4).

In addition to the map plot, we also create a histogram from the same DataFrame:
```
map_plot = df.hvplot.scatter(x='x', y='y', datashade=True, height=300, width=400)
hist_plot = df.where((df.SOG>0) & (df.SOG<50)).hvplot.hist("SOG",  bins=20, width=400, height=200) 
```
To link the two plots, we use HoloViews’ link_selections function:
```
from holoviews.selection import link_selections
linked_plots = link_selections(map_plot + hist_plot)
```
That’s all! We can now perform spatial filters in the map and attribute value filters in the histogram and the filters are automatically applied to the linked plots:

Linked brushing demo using ship movement data (AIS): filtering records by speed (SOG) reveals spatial patterns of fast and slow movement.

You’ve probably noticed that there is no background map in the above plot. I had to remove the background map tiles to get rid of an error in Holoviews 1.13.4. This error has been fixed in 1.14.0 but I ran into other issues with the datashaded Scatterplot.

It’s worth noting that not all plot types support linked brushing. For the complete list, please refer to [holoviews.org]
11 December 2020
11:00
CARTO Blog: Our Thoughts as MapboxGL JS v2.0 Goes Proprietary
sur Planet OSGeo

This week, Mapbox announced that they were changing the license of their MapboxGL JS library as part of their latest v2.0 release. The library has gone from an Open Source ...
10:00
CARTO Blog: Announcing the CARTO Scientific Committee
sur Planet OSGeo

CARTO has been at the forefront of the development of Spatial Data Science, a subset of Data Science that focuses on the unique characteristics of spatial data, moving beyo...
10 December 2020
16:57
gvSIG Team: 16th International gvSIG Conference: Recording of presentations and workshops available
sur Planet OSGeo

The presentations given at 16th International gvSIG Conference, that were held from November 4th to 6th in online mode, are now available.

Recording of presentations that were given in English, Spanish or Portuguese, as well as the workshop in Spanish about “Normalización radiométrica e índices de vegetación en mapeo de incendios” are available at the Conference website.

If you couldn’t follow the live conference you can watch the videos of the different sessions and the workshop and download the presentations now.

Don’t miss them and see you in the next gvSIG Conference!
16:42
gvSIG Team: 16as Jornadas Internacionales gvSIG: Disponible la grabación de las ponencias y el taller
sur Planet OSGeo

Ya están disponibles las presentaciones realizadas en las 16as Jornadas Internacionales gvSIG, que se celebraron de forma online del 4 al 6 de noviembre.

También está disponible la grabación, tanto de las ponencias que se realizaron en español, inglés y portugués, como del taller sobre “Normalización radiométrica e índices de vegetación en mapeo de incendios”que se impartió durante las jornadas.

Si no pudiste seguir las jornadas en directo ahora puedes disponer de la grabación de las distintas sesiones, y también del interesante taller realizado.

¡Os esperamos en las siguientes jornadas!
1:00
Jo Cook: Simple, but not too simple
sur Planet OSGeo

Jimee, Jackie, Tom & Asha, CC BY-SA 2.0 [https:]] , via Wikimedia Commons

A focus of mine over the last few years has been how new users for software are enabled by good documentation, or conversely how easy it is to inadvertently put people off with the language you use. There are countless articles on this, around the use of terms such as “just”, or “simply”, and I’ve made observations myself on other examples over the last couple of years. However, I recently read a series of articles (kicked off by this one from Julia Evans) that made me realise that the debate is actually more nuanced than I had considered, and that there are downsides to using language that’s too simple.
Avoid Jargon
You don’t want to put off complete beginners by overwhelming them with unfamiliar jargon, but avoiding necessary technical terms will be counter-productive in the long-term, as it will be a barrier to further searching and learning. A good balance would be to avoid unnecessary jargon, but introduce vital technical terms with a friendly explanation.

For example, here are three ways of introducing the same concept, namely making a change to some documentation for a project that is hosted on GitHub. Note I have omitted some elements of the process in step three, for brevity. Don’t @ me.

1) All jargon: Submit changes to our documentation by forking the repository and submitting a pull-request.

2) No jargon: Submit changes to our documentation by copying the code and sending us a version with your changes in it.

3) Friendly explanation: To submit changes to our documentation, firstly you’ll need a user account on GitHub. Then make a copy (or fork) our repository under your own account, make the changes there using the in-built text editor, and then submit a request back to us (a pull request). We will review your suggestions and hopefully approve them. If you are unclear about any of these steps, see the documentation at [https:]] .

From the perspective of a beginner, the first approach would probably be off-putting as it assumes you already know what the terms ‘forking’ and ‘pull request’ means, so our beginner starts their journey by feeling stupid.

Approach two is an attempt to simplify the language by using roughly equivalent non-technical terms but it doesn’t explain how to copy the code and send the changes, and our plucky beginner will be no better off when they do eventually meet the terms ‘forking’ and ‘pull request’.

Approach three is more verbose, I admit, but it introduces all the terms, explains the process, and provides guidance if needed.
When is plain language too plain?
This is where it gets tricky. Plain language is more accessible (for example to people with disabilities), but at the same time if you use language that’s too plain for your intended audience, then you risk appearing condescending. The key element is the for your intended audience part. One definition of plain language states that it is “Language that allows readers to make an informed decision about the content because it considers their literacy levels, cognitive abilities, contexts, wants, needs, attitudes and challenges” (Candice Burt, via [https:]] ). In what seems to have been a well-received experiment, the journalism website ProPublica published some articles and editors notes on disability rights alongside their standard text ( [https:]] ). Your reaction may vary when reading the plain language translation. Personally I wince at using “caring” or a derivative of it, 4 times in a 3-sentence paragraph, but I like the general sentiment.

However, the level of plain language used does need to take into account the expected audience. Sumana Harihareswara writes of mixed reactions to a FAQ on sunsetting Python 2 that was written in a plain language style. When I read that, elements of it do make me cringe, though partly that’s to do with the same issue of repeating words, but also starting sentences with “And”. I think it ought to be possible to write in plain language without doing either of those things.

Finally, I was recently introduced to Hemingwayapp, which does a good job of assessing the readability grade of your writing, and suggests appropriate changes. Not everyone uses a full-blown word-processing package so this is a useful service (and free). Writing for your audience, but also ensuring you don’t alienate or condescend, is a really fine balance to hit- and thinking about these two issues in depth has given me even more respect than I previously had for technical writers!
09 December 2020
11:02
gvSIG Team: Análisis evolución COVID-19 en Uruguay con gvSIG Online
sur Planet OSGeo
Los que nos seguís habitualmente sabéis que la Infraestructura de Datos Espaciales de Uruguay utiliza gvSIG Online como base tecnológica. Aquí podéis ver una presentación sobre ello. Al final de dicha presentación se comenta que aprovechando las ventajas de gvSIG Online, sin límites de uso de ningún tipo al ser software libre, el Gobierno de Uruguay está generando distintos geoportales que van más allá del alcance inicial previsto de disponer de un Geoportal para la IDE de Uruguay, y que entre esos usos está el análisis de los casos del COVID-19.

Pues bien, estos días la prensa generalista ha publicado noticias sobre la evolución de la pandemia, en las que se hacen eco de los mapas y animaciones generados por el Ministerio de Salud Pública con gvSIG Online.

Aquí os dejamos un par de enlaces, de dos de los varios medios de prensa en los que se muestra está información:
- Subrayado: [https:]]
- El País: [https:]]
Y el vídeo con gvSIG Online mostrando información sobre los casos de COVID-19 en Montevideo:
10:30
Jackie Ng: My new rig
sur Planet OSGeo
This past week, I made the final decision to retire my old PC used for gaming and dev on my various open source projects and start shopping out for a new PC.
The main reason for the decision was my daily YouTube feed being subliminally inserted with many videos praising the (just-released) AMD Ryzen 5000 series of CPUs and the AMD Radeon RX 6000 series of GPU and how they were absolutely trouncing Intel and Nvidia in their respective CPU and GPU performance.
I also haven't been a fan of Intel CPUs since the advent of the meltdown and spectre vulnerabilities and Linus Torvalds' remarks about Nvidia have long stuck with me and my open source sensibilities, so I knew my next PC was going to have an AMD CPU and an AMD GPU. Now for me personally, I'm more of a coder than a gamer so while most of the competition-trouncing benchmarks thrown around were gaming-oriented, I was more interested in any benchmarks on developer-style workloads. One particular benchmark on one particular video caught my attention and told me that not only will my next PC be all AMD, I must get this next PC yesterday!

That's right, the new top-of-the-line AMD Ryzen 5950x compiles the Chromium browser (the software whose C++ codebase is most notorious for long build times) in around 45 minutes! Since the C++ codebases I work with are way smaller than Chromium's, but still took a considerable time to build on my old 2012 rig I was salivating at the thought of being able to compile MapGuide/FDO/GDAL/etc in 5-10 minutes on my brand new Ryzen-powered beast.
So then I started to look around to see who would offer such a beast of a PC in my home country of Australia. This eventually lead me to PC Case Gear (PCCG) which offered pre-built Intel and AMD Ryzen Gaming PCs at various pricing tiers. Some people may tell me that I should buy the components and build the PC myself, but I'm more of a software person than a hardware person so when it comes to a new PC, I prefer to go a with a pre-built one than risk screwing thing up building a new PC myself.
My personal budget for this new PC was to be no more than $5000 AUD. This sadly put any pre-built systems with a Ryzen 5950x out of my price range, so I settled on their Elite 6800 XT gaming system, whose main components of interest were:
- AMD Ryzen 9 5900x
- AMD Radeon RX 6800 XT
- 4TB (2x2) SSD
- 32 GB of DDR4 RAM
- Windows 10 Home pre-installed
So I placed my order and gleefully waited in anticipation for this box to arrive. Then reality hit.
These AMD CPUs were selling faster than toilet paper during the early stages of this pandemic. Demand so wildly exceeded supply that you even had dedicated YouTube livestreams tracking availability of AMD Ryzen stock! And so a few days after placing the order, I sadly got the phone call from PCCG that they run out of stock on the Ryzen 9 5900x and for reasons unknown (miscalculation of inventory perhaps?) their website had erroneously reported the PC I ordered as being in stock. In light of this, they offered to replace the out-of-stock Ryzen 9 5900x with a less-but-still-powerful Ryzen 7 5800x with a $300 AUD discount. My dev-oriented mindset at this point was "well... it still compiles Chromium in under 90 minutes! So it should still be great for developer workloads relatively-speaking", so I accepted their revised offer.
A few days later, my doorbell rings and it arrived.

PCCG obviously took great care in packaging by wrapping the PC in so much foam and bubble wrap that it could double as a padded cell for a psychiatric hospital. Several minutes of cutting all the wrapping and unboxing later, my new rig was ready to be powered on and ready to rock!

Now for some developer-oriented first impressions/observations.Windows 10 Home observationsThis PC (like most computers these days) came with Windows 10 Home pre-installed and is my first computing device with this particular edition installed. My experiences with Windows 10 thus far have either been from playing with their preview builds or using the Pro edition on computers at work. I've known that home editions of past Windows releases really gimped out on the features that I needed or would be of interest to me as a developer. But Windows 10 home edition was a real surprise on this front.
Firstly, it includes IIS. So I can install MapGuide on this with IIS/.net configuration. Previous versions of Windows left IIS as a pro-only feature.
The other big surprise was Windows 10 Home supports WSL2. This one is a game-changer and was a feature I seriously did not expect to be appear in the Home edition. As someone who builds software for both Windows and Linux, being able to build (and debug) for both OSes from a single host OS without needing to spin up separate virtual machines is a massive productivity boost!
And by supporting WSL2, it means I can also spin up docker containers as Docker for Windows uses WSL2 for its container backend. I can run the new docker-based MapGuide/FDO build system completely inside an Ubuntu WSL2 distro, while building MapGuide/FDO for Windows at the same time!
MapGuide/FDO observationsSo with my new rig up and running, the first item of order was obviously to get my dev environment all set up and see how fast MapGuide/FDO will take to build from a clean SVN checkout.
- FDO takes 17 minutes (release build, windows)
- MapGuide takes 15 minutes (release build, windows)
- Linux numbers TBD, but I'm expecting comparable numbers
I have never seen C++ compiler output whiz by so fast! I can only imagine how much faster this would be if I my new PC had the original Ryzen 9 5900x (or even better, if the Ryzen 9 5950x was in stock and not so expensive to fit within my budget)
When all the compiler output is whizzing by, you start to notice the slower parts of the build because their compiler output isn't ticking along as fast. In the case of FDO, it noticeably slowed down when building the internal OpenSSL library. It turns out that the OpenSSL build system is woefully un-parallel on Windows, using only 16% of my available CPU during the entire build.
Overall though, I really like these numbers, which only go down once we start doing actual dev work where we won't be building thirdparty libs and certain projects over and over.In closingSo far, I am very happy with my new purchase. PCCG were very speedy in their delivery and very helpful in their communications.
My last PC lasted a solid 8 years. I'm certain this new PC will last me a good decade. The only slight disappointment was not being able to get the Ryzen CPU I originally wanted, but then again many others can't get the Ryzen CPU they want either!
9:00
Paul Ramsey: Mapbox and Morrison
sur Planet OSGeo
Yesterday, Mapbox announced that they were moving their Mapbox GL JS library from a standard BSD license to a new very much non-open source license.

Joe Morrison said the news “shook” him (and also the readers of the Hacker News front page, well done Joe). It did me as well. Although apparently for completely different reasons.

Mapbox is the protagonist of a story I’ve told myself and others countless times. It’s a seductive tale about the incredible, counterintuitive concept of the “open core” business model for software companies.
– Joe Morrison

There’s a couple things wrong with Joe’s encomium to Mapbox and “open core”:
- first, Mapbox was never an open core business;
- second, open core is a pretty ugly model that has very little to do with the open source ethos of shared intellectual pursuit.
Mapbox was never Open Core
From the very start (well, at least from the early middle), Mapbox was built to be a location-based services business. It was to be the Google Maps for people who were unwilling to accept the downsides of Google Maps.

Google Maps will track you. They will take your data exhaust and ruthlessly monetize it. They will take your data and use it to build a better Google Maps that they will then re-sell to others.

If you value your data at all (if you are, say, a major auto maker), you probably don’t want to use Google Maps, because they are going to steal your data while providing you services. Also, Google Maps is increasingly the “only game in town” for location based services, and it seems reasonable to expect price increases (it has already happened once).

Nobody can compete with Google Maps, can they? Why yes, they can! Mapbox fuses the collaborative goodness of the OpenStreetMap community with clever software that enables the kinds of services that Google sells (map tiles, geocoding, routing, elevation services), and a bunch of services Google doesn’t sell (like custom map authoring) or won’t sell (like automotive vision).

But like Google, the value proposition Mapbox sells isn’t in the software, so much as the data and the platform underneath. Mapbox has built a unique, scalable platform for handling the huge problem of turning raw OSM data into usable services, and raw location streams into usable services. They sell access to that platform.

Mapbox has never been a software company, they’ve always been a data and services company.

The last company I worked for, CARTO, had a similar model, only moreso. All the parts of their value proposition (PostgreSQL, PostGIS, the CARTO UI, the tile server, the upload, everything) are open source. But they want you to pay them when you load your data into their service and use their software there. How can that be? Well, do you want to assemble all those open source parts into a working system and keep it running? Of course not. You just want to publish a map, or run an analysis, or add a spatial analysis to an existing system. So you pay them money.

Is Mapbox an “open core” company? No, is there a “Mapbox Community Edition” everyone can have, but an “Enterprise Edition” that is only available under a proprietary license? No. Does Mapbox even sell any software at all? No. (Yes, some.) They (mostly) sell services.

So what’s with the re-licensing? I’ll come back to that, but first…
Open Core is a Shitty Model
Actually, no, it seems to be a passable monetization model, for some businesses. It’s a shitty open source model though.
- MongoDB has an open source core, and sells a bunch of proprietary enterprise add-ons. They’ve grown very fast and might even reach sufficient velocity to escape their huge VC valuation (or they may yet be sucked into the singularity).
- Cloudera before them reached huge valuations selling proprietary add-ons around the open Hadoop ecosystem.
- MySQL flirted with an open core model for many years, but mostly stuck to spreading FUD about the GPL in order to get customers to pay them for proprietary licenses.
Easily the strangest part of the MySQL model was trash-talking the very open source license they chose to place their open source software under.

All those companies have been quite succesful along the axes of “getting users” and “making money”. Let me tell you why open core is nonetheless a shitty model:
- Tell me about the MongoDB developer community. Where do they work? Oh right, Mongo.
- Tell me about the Cloudary developer community? Where do they work?
- Tell me about the MySQL developer community? Where to they work? Oh right, Oracle. (There’s a whole other blog post to be written about why sole corporate control of open source projects is a bad idea.)
A good open source model is one that promotes heterogeneity of contributors, a sharing of control, and a rising of all boats when the software succeeds. Open core is all about centralizing gain and control to the sponsoring organization.

This is going to sound precious, but the leaders of open core companies don’t “care” about the ethos of open source. The CEOs of open core companies view open source (correctly, from their point of view) as a “sales channel”. It’s a way for customers to discover their paid offerings, it’s not an end in itself.

We didn’t open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.
– Dev Ittycheria, CEO, MongoDB

So, yeah, open core is a way to make money but it doesn’t “do” anything for open source as a shared proposition for building useful tools anyone can use, for anything they find useful, anytime and anywhere they like.

Check out Adam Jacob’s take on the current contradictions in the world of open source ethics; there are no hard and fast answers.
Mapbox Shook Me Too
I too was a little shook to learn of the Mapbox GL JS relicensing, but perhaps not “surprised”. This had happened before, with Tilemill (open) morphing into Mapbox Studio (closed).

The change says nothing about “open source” in the large as a model, and everything about “single vendor projects” and whether you should, strategically, believe their licensing.

I (and others) took the licensing (incorrectly) of Mapbox GL JS to be a promise, not only for now but the future, and made decisions based on that (incorrect) interpretation. I integrated GL JS into an open source project and now I have to revisit that decision.

The license change also says something about the business realities Mapbox is facing going forward. The business of selling location based services is a competitive one, and one that is perhaps not panning out as well as their venture capital valuation (billions?) would promise.

No doubt the board meetings are fraught. Managers are casting about for future sources of revenue, for places where more potential customers can be squeeeeezed into the sales funnel.

I had high hopes for Mapbox as a counterweight to Google Maps, a behemoth that seems likely to consume us all. The signs that the financial vice is beginning to close on it, that the promise might not be fulfilled, they shake me.

So, yeah, Joe, this is big news. Shaking news. But it has nothing to do with “open source as a business model”.
1:00
PostGIS Development: PostGIS 3.1.0beta1
sur Planet OSGeo
The PostGIS Team is pleased to release the first beta of the upcoming PostGIS 3.1.0 release. This version is exposes some of the new performance and feature enhancements in not yet relesed GEOS 3.9 as well as numerous speed enhancements not requiring newer GEOS. Requires GEOS 3.6+ and PostgreSQL 9.6+. To use MVT you will need protobuf-c 1.1. or higher.

Best served with:
- PostgreSQL 13.1, GEOS 3.7 or higher is recommended.
- pgRouting 3.1.1
Continue Reading by clicking title hyperlink ..
07 December 2020
12:29
Florentina Musat: Nyquil Memes Are Famous in Sky
sur Planet OSGeo

Such are exceptionally uncommon situations of Nyquil Memes
Without better information on the human condition some time ago, when Siddhartha Gautama's representationalism more likely than not been in any event changing, the cognizance in itself is a reality, and the main reality when contrasted. We can't state the simple things and objects of the universe with conviction the profundities of enduring experienced at that time. In this manner, one of the establishing standards that life is enduring. That information in human awareness in their type of portrayals are in a consistent change and adjustment, along these lines being something close of being illusionary, are past the range of the advancement of however in that the truth where we make our inferences from has fundamentally modified since his reality.

The authenticity of cosmology and its sister, quantum material science, has changed the human impression of presence and climate. The authenticity of human life systems has likewise changed the very pith of being. In an immense detail of such properties as DNA, cell cycles, and nervous system science, we currently know our feeling of the truth depends on. In this way, as the human condition has likewise improved because of clinical creations made since the logical upset of the 1920s, mental medical services, and so forth, the establishing standards of Buddhism, contrasted, and logical authenticity is subsequently overwhelmed the innovation of thought. Also Visit Nyquil Memes, Dayquil Memes And Funny Memes.
11:34
pycsw Team: pycsw turns 10!
sur Planet OSGeo

10 years – Happy birthday pycsw! ?
This year (02 December) marks the 10th anniversary of the pycsw project. From the initial commit on SourceForge, and subsequent announcement, of the project, pycsw has evolved into a stable, production ready and core spatial data infrastructure (SDI) component for disseminating metadata via the OGC CSW specification.

pycsw powers numerous high profile open data / SDI activities, including US Data.gov, LINZ, Geodata.gov.gr, IOOS, NOAA, WMO WOUDC, UN WFP, Copernicus and GEOSS. The flexible nature of the project has also resulted in integration with leading open data management systems such as CKAN and GeoNode.

From day one, pycsw has always strived to be OGC Compliant. The project continues to be a leading OGC Reference Implementation of CSW. In addition, pycsw continues as a long standing OSGeo project and a core component of the growing ecosystem of geopython projects for the open source geospatial community.
Future plans
The project will continue to evolve into the future. pycsw’s flexible nature will continue to support new metadata formats, as well as integration with downstream applications. To support OGC CSW as a baseline OGC web service specification, as well as the evolving OGC API efforts to modernize web service APIs, pycsw will continue to support CSW 2/3, as well as the emerging OGC API - Records specification.

Thank you to the pycsw community, OSGeo, OGC and beyond for your support and use of our lightweight, flexible and OGC compliant metadata catalogue server – happy birthday pycsw!

Sincerly

The pycsw Project Steering Committee
06 December 2020
19:00
Free and Open Source GIS Ramblings: Plotting large point CSV files quickly & interactively
sur Planet OSGeo
Even with all their downsides, CSV files are still a common data exchange format – particularly between disciplines with different tech stacks. Indeed, “How to Specify Data Types of CSV Columns for Use in QGIS” (originally written in 2011) is still one of the most popular posts on this blog. QGIS continues to be quite handy for visualizing CSV file contents. However, there are times when it’s just not enough, particularly when the number of rows in the CSV is in the range of multiple million. The following example uses a 12 million point CSV:

To give you an idea of the waiting times in QGIS, I’ve run the following script which loads and renders the CSV:
```
from datetime import datetime

def get_time():
    t2 = datetime.now()
    print(t2)
    print(t2-t1)
    print('Done :)')

canvas = iface.mapCanvas()
canvas.mapCanvasRefreshed.connect(get_time)

print('Starting ...')

t0 = datetime.now()
print(t0)

print('Loading CSV ...')

uri = "file:///E:/Geodata/AISDK/raw_ais/aisdk_20170701.csv?type=csv&amp;xField=Longitude&amp;yField=Latitude&amp;crs=EPSG:4326&amp;"
vlayer = QgsVectorLayer(uri, "layer name you like", "delimitedtext")

t1 = datetime.now()
print(t1)
print(t1 - t0)

print('Rendering ...')

QgsProject.instance().addMapLayer(vlayer)
```
The script output shows that creating the vector layer takes 02:39 minutes and rendering it takes over 05:10 minutes:
```
Starting ...
2020-12-06 12:35:56.266002
Loading CSV ...
2020-12-06 12:38:35.565332
0:02:39.299330
Rendering ...
2020-12-06 12:43:45.637504
0:05:10.072172
Done :)
```
Rendered CSV file in QGIS

Panning and zooming around are no fun either since rendering takes so long. Changing from a single symbol renderer to, for example, a heatmap renderer does not improve the rendering times. So we need a different solutions when we want to efficiently explore large point CSV files.

The Pandas data analysis library is well-know for being a convenient tool for handling CSVs. However, it’s less clear how to use it as a replacement for desktop GIS for exploring large CSVs with point coordinates. My favorite solution so far uses hvPlot + HoloViews + Datashader to provide interactive Bokeh plots in Jupyter notebooks.

hvPlot provides a high-level plotting API built on HoloViews that provides a general and consistent API for plotting data in (Geo)Pandas, xarray, NetworkX, dask, and others. (Image source: [https:]] )

But first things first! Loading the CSV as a Pandas Dataframe takes 10.7 seconds. Pandas’ default plotting function (based on Matplotlib), however, takes around 13 seconds and only produces a static scatter plot.

Loading and plotting the CSV with Pandas

hvPlot to the rescue!

We only need two more steps to get faster and interactive map plots (plus background maps!): First, we need to reproject the lat/lon values. (There’s a warning here, most likely since some of the input lat/lon values are invalid.) Then, we replace plot() with hvplot() and voilà:

Plotting the CSV with Datashader

As you can see from the above GIF, the whole process barely takes 2 seconds and the resulting map plot is interactive and very responsive.

12 million points are far from the limit. As long as the Pandas DataFrame fits into memory, we are good and when the datasets get bigger than that, there are Dask DataFrames. But that’s a story for another day.
05 December 2020
14:47
pycsw Team: pycsw 2.6.0 released
sur Planet OSGeo
The pycsw team announces the release of pycsw 2.6.0.

This release brings various enhancements to OpenSearch temporal support, cloud enhancements, and 12 factor support. This release also drops all Python 2 support given the Python 2 end of life which occured on 01 January 2020. Users are strongly encouraged to update their deployments to Python 3 as soon as possible.
Source and binary downloads:
The source code is available at:

[https:]]

PyPI packages are available at:

[https:]]
Version 2.6.0 (2020-12-05):
[Bulleted list of enhancements / bug fixes]
- fix GetRecords startposition empty parameter fixes
- update OpenSearch temporal extent query support
- add 12 factor support
- support environment variables in configuration
- add kubernetes and helm configurations
- fix quoting for PostgreSQL backends
- add logging switch to pycsw-admin.py CLI to stdout
- safeguard XML as bytes to unicode
- update core model xml column to Unicode on repository creation
- handle different formats for CRS code input
- add test for invalid gml:posList geometry
- drop all Python 2 support
Testers and developers are welcome.

The pycsw developer team. [https:]]
14:21
Free and Open Source GIS Ramblings: Dashboards in QGIS
sur Planet OSGeo

If you are following QGIS topics on social media, you may have already seen this but if you don’t, I recommend having a look at Tim Sutton’s most recent adventures in building dashboards with QGIS:

Another dashboard update! This adds a new font attribute to the dashboard table and adds column icons. Needs the free UN-OCHA glyph font icons: [https:]]

Latest GeoPackage containing all the logic for the above image is available here: [https:]] pic.twitter.com/EFxvVuLsYx

— Tim Sutton (@timlinux) December 1, 2020

The dashboard is built using labeling and geometry generator functionality. This means that they work in the QGIS application map window as well as in layouts. As hinted at in the screenshot above, the dashboard can show information about whole layers as well as interactive selections.

Here’s a full walk-through Tim published yesterday:

You can follow the further development via Tim’s tweets or the dedicated Github issue (where you can even find an example QGIS dashboard project in a GeoPacakge for download).
13:24
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.2.0
sur Planet OSGeo
I'm glad to release a new update of the Semi-Automatic Classification Plugin v. 7.2.0.
This version includes several bug fixes and new features, and now all the tools are converted to multiprocess, which should result in faster processing. In particular the following tools were updated:
- the tool Classification dilation
- the tool Classification erosion
- the tool Cloud mask
- the tool Class signature
- the tool Mosaic
- the tool PCA
- the scatter plot calculation
Also, the tool Band calc has been improved, and now it is possible to use the variable "bandset{LIST_OF_BANDSETS}bNUMBER_OF_BAND"for using a list of bands (for instance bandset{1,2}b1 is equivalent to ["bandset1b1","bandset2b1"]).For instance it can be used for calculating sum of bands:sum("bandset{1,2,3}b1")
for the sum of the first bands of the bandsets 1, 2, and 3, or similarly using ranges:sum("bandset{1:3}b1")
or list of rangessum("bandset{1:2, 3:4}b1")
Please read the user manual for further details.
For any comment or question, join the Facebook group about the Semi-Automatic Classification Plugin.
04 December 2020
10:00
CARTO Blog: How to Create Maps from Snowflake using CARTO & SQL
sur Planet OSGeo

Simpler data workflows for Snowflake users
10:00
CARTO Blog: Analyzing UK Covid Recovery & Mobility with Avison Young
sur Planet OSGeo

With the pandemic leading to widespread retail slowdown and permanent work-from-home policies there has been little demand for empty spaces which has greatly impacted the c...
02 December 2020

11:46

Cameron Shorter: Halfway status - Cross-organizational glossary pilot

sur Planet OSGeo

This interim status report outlines achievements, early findings and outstanding tasks for our cross-organizational glossary pilot project.

Pilot Overview

Glossaries are easy to set up for simple examples but extremely hard to scale - especially when a project wants to inherit terms from other organizations. This pilot has been set up to test cross-domain management of glossaries. We started in August 2020, and plan to have tested pilot goals by March 2021.

We are testing glossary software, standards, and processes, and applying them to cross-organizational use cases within the geospatial mapping domain.

For more details, refer to our manifesto.

Pilot contributors: Cameron Shorter, Alyssa Rock, Ankita Tripathi, Naini Khajanchi, Ronald Tse, Reese Plews, Rob Atkinson, Nikos Lambrinos, Erik Stubkjær, Brandon Whitehead, Ilie Codrina Maria, Vaclav Petras

Current status

Our interim status as the start of December 2020 is as follows:

Task	% Complete
Define glossary goals	90%
Establish implementation Plan	80%
Establish a healthy community	70%
Implement/adopt software platform	70%
Establish schemas for terms	70%
Define sentence structure for terms	70%
Connect external glossaries	10%
Collate and clean Open Source Geospatial (OSGeo) terminology	60%
Document template governance processes	10%

Goals

Task: Define glossary goals.

Understanding the problem is the first step needed to then address it.

Figure: Connected glossaries, source

Status:

We feel we have articulated the problem and associated use cases reasonably well. Refer to the Glossary Pilot Manifesto and accompanying presentations.

Implementation plan

Task: Establish implementation Plan

Status:

Within the Glossary Pilot Manifesto we articulated steps for standing up a cross-organizational glossary pilot. We have been steadily working against this plan.

Community

Task: Establish a healthy community:

Apache, one of the leading open source foundations prioritizes “community over code”. A strong community will solve any technical challenges faced.

Status:

We have attracted a motivated, competent, and cross-functional team of 5 to 10 people (depending on how you count), who are steadily working through our backlog of tasks. Collectively we have decades of experience with glossaries, tech writing, standards, software, and the geospatial domain we are initially focusing on.
We have a weekly status meeting, sometimes complemented by additional meetings, along with a slack channel, and email list.

Outstanding:

We have only attracted one of the many OSGeo open source projects to sign up as a pilot. This is likely because we haven’t made the signup process easy enough yet, and our tools and processes need improving.
After completing the pilot and releasing an alpha version, we’d want to scale our community into other domains (beyond our current spatial domain focus).

Glossarist platform

Task: Implement/adopt software platform

Status:

We’ve adopted the glossarist open source software to manage terminology. This provides terminology management of terms, and publishing of terms via a standards based web service.
Ribrose, who develop this software, has been working with us to update the software to address use cases and feedback we are finding during testing.
Extra functionality is expected to be included during the remainder of this pilot.

Schema

Task: Establish schemas for terms

Figure: Glossary schema, sourcing from upstream glossaries, source

Status:

We’ve adopted the Simple Knowledge Organisation System (SKOS) standard for selecting the fields to use when describing terminology.

Sentence structure

Task: Define sentence structure for terms.

Status:

For sentence structure, we’ve adopted 16.5.6 Definitions, ISO/IEC Directives, Part 2
Principles and rules for the structure and drafting of ISO and IEC documents

“The definition shall be written in such a form that it can replace the term in its context. …”
Example: 2.1.17 die: metal block with a shaped orifice through which plastic material is extruded

While aligning with uses in specific spatial ISO settings, many glossaries use alternative sentence structures, and this is something I’m expecting we’ll need to revisit.

Connect glossaries

Task: Connect external glossaries

Status:

In theory, we are very close to connecting two glossaries. In practice, we still need to set this up, which is a focus for the rest of this pilot.

Governance

Task: Document template governance processes

Figure: Glossary governance, source

Status:

While we have been discussing and making use of our own unwritten governance process, we are yet to write this down and provide it as template guidance.

Spatial use case

Task: Collate and clean Open Source Geospatial (OSGeo) terminology

Status:

We’ve collated OSGeo terminology from around ten OSGeo glossaries along with OGC and ISO terms.
These terms have been aligned with writing rules.
We’ve just started looking at terms from the GRASS project, and plan to integrate these too.

10:00
CARTO Blog: Predicting Traffic Accident Hotspots with Spatial Data Science
sur Planet OSGeo

Road traffic injuries are among the ten leading causes of death worldwide and they are the main cause of death among young adults aged 15-29 years [1]. In addition to the t...
01 December 2020
10:00
CARTO Blog: Lifesight Human Mobility & Footfall Data now available in CARTO
sur Planet OSGeo

During the COVID-19 pandemic a key challenge has been sourcing data that is real-time enough to reflect the weekly and daily changes that affect consumer behavior. Human mo...
1:00
Jo Cook: On the many ways in which you can contribute to open source
sur Planet OSGeo

As a recipient of a Google Peer Bonus, I was given the opportunity to submit a guest post to the Google Open Source Blog, published on October 27th 2020. For my own archives, and because I didn’t particularly like some of the edits they made, here’s my original version.

I was recently awarded a Google Open Source Peer Bonus, which was all kinds of awesome, but also proof that you can contribute things of value to open source projects, and indeed build a career in it, without being a hard-core coder. I can github, it’s true, but my actual coding skills are definitely limited to the occasional python or shell script! So how, as a non-coder can I, and others like me, contribute to open source in a meaningful way?
Help with documentation!
This is incredibly valuable, particularly if you are new to a project! Firstly, developers and maintainers of projects are often focused, for good reason, on fixing bugs and improving the software. Documentation is harder for them to prioritise, and sometimes gets neglected. If you can help with this, then your contributions will be greatly appreciated. Secondly, if you’re very familiar with how to install and run a particular package, or even if you already have all the dependencies installed, then it’s very easy to miss a step, or for your instructions to be ambiguous. However, if you’re a beginner, you are best placed to ensure that instructions and step-by-step guides are easy to follow, don’t skip vital steps, and don’t use off-putting language.

Also, if you have the opportunity to get involved in projects like Google Season of Docs as a mentor or a participant, as I did in 2019, go for it because it’s hugely rewarding!
Get involved in the community!
Can you help on mailing lists, or by organising events? One of the best things I have done was to get involved in the nascent Open Source Geospatial Foundation (OSGeo) back in 2006. I was persuaded to set up a local chapter in the United Kingdom, which is still going strong 14 years later at [https:]] . We’ve hosted a global conference (FOSS4G) and several UK events; and an online-only event this year. We’ve also managed to financially support a number of open source projects by providing an annual sponsorship, or by contributing to the funding of a specific improvement. I’ve met so many great people because of my involvement in OSGeo, some of which have become colleagues and good friends.

The view from the stage at FOSS4G 2013, photo by me, CC BY-NC-2.0
Talk about projects!
Can you talk at a conference about your experiences with a project, or perhaps write a case study? Evidence that particular packages can be used successfully in real-world situations are incredibly valuable, and can help others put together business cases for considering an open source solution.
Can you make things easier for people?
When I first started using open source software, the packages I needed were often hard to install and configure on windows, and had to be started using the command prompt, which is intimidating for beginners. To scratch a problem-solving itch, I packaged them up onto a USB stick, added some batch files to make them load properly from an external drive, added a little menu for starting them, and Portable GIS was born. 12 years, a few iterations, a website and a GitLab repository later, it has been downloaded thousands of times, and is used in situations such as disaster relief, where installing lots of software rapidly on often old pcs is not really an option. I didn’t need any coding skills for this, beyond knowing how to refer to relative drive paths in windows.

Once you get proficient in something, use your new knowledge to help others. Some areas of “modern” software use and development, such as online repositories like GitHub or GitLab are extremely intimidating to new users, and create a huge barrier to participation. If you can help people get over the fear-inducing first pull request, you will empower them to keep on contributing. I confess, my first pull request was a slightly puerile contribution to the Vaguely Rude Place-names map back in 2013! Since then, however, taking a leaf from the Python “Don’t be afraid to commit” workshop, I have run a few training events along a similar line at conferences and hopefully helped a few people take that first step.

In summary, 16 years after I first found out about it, open source is now fundamental to my career, as well as being something that I am truly passionate about. It has shaped my life in many ways. I hope that my experiences might help some people who also consider themselves to be non-coders to get involved, and to realise that their contributions are equally as valuable as bug fixes and patches.
30 November 2020
11:40
Andrea Antonello: SMASH 1.6.1 is out geo-tiffs and -fences
sur Planet OSGeo

Today we released SMASH 1.6.1 to the stores.
The main reason we are doing this is because there was a startup bug that was freezing SMASH, mostly on Xiaomi devices. If you experienced something like this: [https:]
...well, update and it will be gone.

That said, we also have some significant additions:
Geotiff support
Up to now we had tiff support needing world files and projection file to be present. Now geotiff tag reading is supported, so "real" geotiffs can be read. This is quite handy, since the image file gets back to be a single one again. Same as for other imagery types it supports overall transparency and single color removal, which allows for some nice technical map overlays (for example):
Geo-fences
Since were we live the COVID lockdown imposed people to only walk a certain distance from home, we decided to lend a helping hand. You now can add fences and make them ring when you enter or exit the radius.
The fence option is available from the bottom toolbar:
Once you hit it, it inserts a new fence in the current map center:
Defining the fence with no sound will result in a grey colored fence to show that it is "inactive":
To modify an existing fence, just place the map center inside its circle and then long tap the fence button. The fence dialog will appear again, this time with an additional possibility to remove the fence.
Now that the fence is active (on enter and exit sound set), the color is red and there are two borders. The green one reminds that on entering there will be a sound, and the blue one that on exit there will be a sound.

Just so you know, fences are not saved into the project, but only in the application preferences. This means that on uninstall or app cache removal.. they will disappear.
Log lines themes
While this is possibly my favorite feature of this release, I have written about it in my last post here, so just check there for descriptions and images.
Other small features
Magnet icon for center on gps: if you are in automatic center on gps mode (double tap on gps icon), it will be visible through a small magnet:

Location permission at startup now allows to access the settings to activate directly background gps usage even when the app is not in use.
Note sharing now also contains the complete OSM url (not sure how that could have been missing up to now):
Project browsing has been made more readable. Not sure how about you, but in my case I just create a new project and using the default proposed name, I simply add something meaningful at the end of it, after an underscore. This allows me to order my projects alphabetically also by timestamp. The problem is that when I want to load an older project, I find myself in this:
The smash_timestamp take the whole line and makes everything unreadable. So now you can activate the upper right filter and the timestamp will be removed from the name and added as additional info ( day and time if available):

I guess that is it for this release. Enjoy!
1:00
GeoNode: GeoNode 3.1 is out!
sur Planet OSGeo
GeoNode 3.1 is out!

This Post is gonna kick things off by summarizing the latest release GeoNode 3.1.

The release fixes several minor, major and security issues. Further GeoNode 3.1 brings several new features you should not miss!
Features GeoNode 3.1
- Python upgrade 3.7+
- Django upgrade 2.2.16
- GeoServer upgrade 2.17.2
- MapStore2 Client Updates:
  - Save Search Services to the Map
  - Save Map Preferences into the adapter model
  - Advanced Style Editor with graphical UI
  - Improved Map Save Widget, specific for GeoNode
- Documentation Updates:
- GNIP-77: GetFeatureInfo Templating For GeoNode
- GNIP-76: Add RTL Support
- Improving GeoNode Theme Library: introducing Jumbotron Slides
- [Admin bulk perms] Implementation of an action to assign bulk permissions on layer to users selected from People and/or Group Django admin forms enhancement #6582
- Review of the current advanced resource workflow implementation enhancement security #6551
- File system operations do not adhere to Django file storage API enhancement in progress #6414
- Nav Toolbar gets distorted when multiple nav bar items are added by the admin enhancement frontend major #6412
- Allow only admins to edit/create keywords enhancement regression #6360
- In home page show only ISO categories currently assigned to some dataset enhancement frontend #6332
- Modify the admin theme customisation feature to allow for the use of a slide show in the home page enhancement feature frontend #6301
- Improve GeoNode OpenID SP Protocol in order to be able to provide access to external clients enhancement security #6273
- Limit "maps using this layer" to maps the user has permission to see enhancement security #6261
- Prevent integrity errors on singleton model save enhancement #6223
- Extend SPCGeonode setup to be customizable using Kubernetes docker enhancement #6208
To rule out any misunderstandings:
Whenever you see GeoNode 2.x make sure your virtual environment uses Python 2.7. In case you see a shining 3 at the end of GeoNode — you have to use Python 3.7+.
For all other things which have been added, do not miss to read — the release notes for GeoNode 3.1!

Last but not least in case you're planning a manual install of version 3, be sure to visit the updated docs. You can report any issues or feature requests at our Issue Tracker @ Github.

Stay healthy & happy GeoNod'ing!

This Website is licensed CC by SA 2012. - GeoNode Contributors. Designed by Spatial Dev
27 November 2020
16:17
OTB Team: Please participate to our survey : How do you use OTB ?
sur Planet OSGeo

Dear community, As you know, Orfeo ToolBox can be used in many ways, on lots of different platforms, and we would like to better know how you use it, what are the difficulties you meet, what you expect in a near future. This small survey (10 mn) will help us to identify some improvements to […]
26 November 2020
17:51
gvSIG Team: Integración de gvSIG Online con gestores de expedientes municipales
sur Planet OSGeo

En la Asociación gvSIG siempre decimos que la realidad se manifiesta en el territorio, y en el caso de una administración local se estima que es más del 80% de la información que se gestiona sobre el municipio tiene atributo o dimensión espacial. Por tanto, herramientas que nos permitan gestionar la información geográfica, nos ayudarán a mejorar la gestión de la realidad municipal.

Así, hablamos de Infraestructuras de Datos Espaciales aplicadas al ámbito municipal, y de su implantación mediante el software libre gvSIG Online. Una solución que nos permite catalogar, gestionar, localizar y compartir fácilmente información mediante visores de mapas web, tanto internamente (privados) como con los ciudadanos (públicos).

Hay otra certeza cuando hablamos de gestión municipal, y es que en la gran mayoría de los casos la gestión de los procedimientos municipales pasan por la gestión de expedientes. Un gran volumen de los datos que maneja un ayuntamiento se introducen mediante el software de gestor de expedientes.

Y ocurre que los expedientes tienen, en su mayoría, un atributo espacial.

Integrando los gestores de expedientes municipales con las Infraestructuras de Datos Espaciales se dota al ayuntamiento de una herramienta de gestión realmente útil y potente. Y de eso hablamos en esta ponencia impartida en las pasadas Jornadas Internacionales de gvSIG.

En ella, además, mostraremos ejemplos de integración de gvSIG Online con gestores de expedientes como Gestiona y OpenSea.

Y si en tu ayuntamiento queréis dar el paso, como tantos otros lo han dado ya, ponte en contacto con nosotros (info@gvsig.com)
10:00
CARTO Blog: COVID-19 Vaccine: Optimizing Cold Chain Transportation
sur Planet OSGeo

Recent promising news regarding COVID-19 vaccine development from Pfizer/BioNTech, Moderna, & AstraZeneca/Oxford University has given the world a glimmer of hope in the...
25 November 2020
1:00
Ecodiv.earth: Access soilgrid data using the WCS protocol
sur Planet OSGeo
- Soilgrids
- Using OWSlib
Soilgrids
The website soilgrids.org provides access to grid layers representing the spatial distribution of soil properties across the globe. The SoilGrids maps are publicly available under the CC-BY 4.0 License. The soilgrids.org provides a convenient portal to explore the available data sets. The data can furthermore be accessed through various services, which are listed on the ISRIC site.

One of the available services is the Web Coverage Service (WCS), which is a standard issued by the Open Geospatial Consortium (OGC). It allows easy remote access to raster layers from a web browser or any other (GIS) program that supports the protocol. What makes it convenient is that one can choose what part of the available data to download based on spatial constraints and other query criteria.

QGIS has a native WCS provider. Downloading the data directly in QGIS is convenient if the goal is to visualize or explore few layers. But what if you use the data as input in e.g. a modeling pipeline in Python? In that case, being able to access the data from Python will greatly simplify your life. Below I’ll provide an example of how to access the data from Python using the OWSlib package.
Using OWSlib
In this post I’ll use the Python OWSlib package. Full documentation about this package can be found here, including installation instructions. The example below is based/inspired on the examples provided in this collection of Jupyter notebooks. Note that there are two versions of the WCS standard, the 1.0.0 and 2.0 versions. The latest version introduces some important improvements. However, I couldn’t get it to work with my dataset, so I’ll use version 1.0.0. As soon as I have figured out what I am doing wrong using version 2.0, I’ll update this post.
Available layers
For each different soil property predicted in SoilGrids there is an independent service. Check the web page maps.isric.org for all the services available. In this post, we’ll use the service for the soil pH as example. First step is to check which grid layers are available using the WebCoverageService function, which issues a GetCapabilities request. As input we provide the URL and the variable.
```
# Load python libraries
from owslib.wcs import WebCoverageService

# Coverage service
var = "phh2o"
url = "http://maps.isric.org/mapserv?map=/map/{}.map".format(var)
wcs = WebCoverageService(url, version='1.0.0')
```
This gives us a service connection. From this the available coverages (maps) can be accessed with the contents property. This returns a dictionary of 24 coverages, combining six standard depth intervals with four quantiles. Below, this dictionary is converted to a list for easier printing. Below only the first 6 layers are shown.
```
# Get the list of maps available for this the service
cov_list = list(wcs.contents)
print(cov_list)
```
```
>> ['phh2o_0-5cm_Q0.05', 'phh2o_0-5cm_Q0.5', 'phh2o_0-5cm_Q0.95',
    'phh2o_0-5cm_mean', 'phh2o_0-5cm_uncertainty',
    'phh2o_5-15cm_Q0.5', ...]
```
We can easily filter out specific layers. For example, with the code below we filter out the layers reporting the average predictions for each of the standard depth intervals.
```
# Get all layers with average predictions
mean_covs = [k for k in wcs.contents.keys() if k.find("mean") != -1]
print(mean_covs)
```
```
>> ['phh2o_0-5cm_mean', 'phh2o_5-15cm_mean', 'phh2o_15-30cm_mean',
    'phh2o_30-60cm_mean', 'phh2o_60-100cm_mean', 'phh2o_100-200cm_mean']
```
Download a layer
To download a layer for a specific region, we can use the getCoverage function. Note that we need to establish the coverage service connection first (we already did this above). The getCoverage function needs the following parameters: the variable (identifier), the coordinate reference systems (crs), the horizontal (resx) and vertical (resy) resolution, the bounding box (bbox) and the output format (e.g., GEOTIFF_INT16).

The format for the crs is defined as follows: urn:ogc:def:crs:EPSG::4326. So we only need to look up the EPSG identifier for the projection in which we want to have the data. The EPSG 4326 is the identifier for the World Geodetic System 1984 (in short WGS 84). For the Amersfoort / RD New projection, the EPSG identifier is 28992. So, we would use crs = 'urn:ogc:def:crs:EPSG::28992'.

The resolution needs to be in the projection’s unit. So, for EPSG 4326 you define the resolution in degrees, while for EPSG 28992 the resolution should be given in meters. The bounding box is defined by the coordinates of the lower left and upper right corner of your region of interest. This takes the following form: bbox = (minimum x, minimum y, maximum x, maximum y).

In the example below, we download the layer for a 16 hectare site in the municipality of Meierijstad in the south of the Netherlands. A new forest garden was established here a few years back, and our students of the Applied Geo-information Science program are involved in a monitoring program as described here. The bounding box of this region is (159750, 403750, 160500, 404750). we’ll download the data in RD New projection and 250 meter resolution.
```
# Download parameters
variable = 'phh2o_0-5cm_mean'
bbox = (159750, 403750, 160500, 404750)
crs='urn:ogc:def:crs:EPSG::28992'
resolution=250

# Get the data
response = wcs.getCoverage(
    identifier=variable, 
    crs=crs,
    bbox=bbox, 
    resx=resolution,
    resy=resolution, 
    format='GEOTIFF_INT16')

# Save the data as geotif
outputname = "{}.tif".format(variable)
with open(outputname, 'wb') as file:
    file.write(response.read())
```
Next step is to inspect and print the map. For that, we’ll use the rasterio library. We can open the file with rasterio.open() function and subsequently read the metadata with the profile method. By wrapping the latter in a with... statement, the statement is executed once the file is opened, and the file is closed when the context manager exits. This means there is no need to manually close the raster file. This use of a so-called context manager is further explained here.
```
# Import libraries
import rasterio
import rasterio.plot

# Read the metadata
filepath = outputname
with rasterio.open(filepath) as src:
    print(src.profile)
```
```
>> {'driver': 'GTiff', 'dtype': 'int16', 'nodata': None, 'width': 3,
    'height': 4, 'count': 1, 'crs': CRS.from_epsg(28992),
    'transform': Affine(250.0, 0.0, 159750.0, 0.0, -250.0, 404750.0),
    'blockxsize': 256, 'blockysize': 256, 'tiled': True, 'compress': 'deflate',
    'interleave': 'band'}
```
We can see that we are dealing with a single layer Geotiff (Gtiff) file, with a dimensions of 3x4 and that the projection is EPSG 28992. No surprise here of course. To learn more about getting raster properties and statistics, see here.

To plot the file, we can use the rasterio.plot.show() function of rasterio. We first import the show function. This time, we do not use the with statement. That means that when we are done, we need to close the connection explicitly with the close() method.
```
# Import the show function from rasterio
from rasterio.plot import show

# Open and plot the raster layer
raster = rasterio.open(filepath)
show(raster)
raster.close()
```
pH H20 for the top 5 cm layer, from soilgrid.org

The show() function does not show the legend. If we want to plot the legend, we need to use matplotlib’s pyplot.imshow function to plot the raster layer, and use the pyplot.colorbar() to plot the legend.
```
# Import pyplot as plt
import matplotlib.pyplot as plt

# Print raster with legend
with rasterio.open(filepath) as src:
    lay = src.read(1)
plt.imshow(lay)
plt.colorbar()
```
The result is shows below. On the x- and y-axes the column and row numbers are given, rather than the coordinates. I haven’t really tried to get it to print with the proper coordinates, as for me this only serves for a quick look at the data anyway.

pH H20 (x 10) for the top 5 cm layer, from soilgrid.org
Import data in GRASS GIS
The advantage of scripting is that one can combine different tools in one pipeline. In the example below, the same code as above is used to download the pH layer. However, the region of interest and resolution are set using the g.region function from GRASS GIS. And the raster layer is imported in the GRASS GIS database.
```
# Coverage service
var = "phh2o"
url = "http://maps.isric.org/mapserv?map=/map/{}.map".format(var)
wcs = WebCoverageService(url, version='1.0.0')

# Select the layer
cov_list = list(wcs.contents)
cov_id = cov_list[3]

# Download parameters
c = gs.region()
bbox = (c['w'], c['s'], c['e'], c['n'])
crs='urn:ogc:def:crs:EPSG::4326'

# Download layer and save as tif
response = wcs.getCoverage(
    identifier=cov_id, 
    crs=crs,
    bbox=bbox, 
    resx=c['nsres'],
    resy=c['ewres'], 
    format='GEOTIFF_INT16')
outputname = "{}.tif".format(cov_id)
with open(outputname, 'wb') as file:
    file.write(response.read())

# Import in grass and delete tif file
grasslayer = re.sub("-", "_", cov_id) 
Module("r.in.gdal", input=outputname, output=grasslayer)
os.remove(outputname)
```
Note that to run the examples above, you need to start GRASS GIS and use the integrated Python editor to run the code. Alternatively, you can start up your favorite Python IDE from the GRASS GIS console. This ensures that you can access the GRASS GIS functionality from within Python. For more information about using Python and GRASS GIS, see this wiki page. If you are new to GRASS GIS, you may want to start with this introduction.

pH H20 (x10) for the top 5 cm layer, from soilgrid.org

See also this site for more information about how to access the soilgrid data in Python. Of, if you want to use the data in R, see see here) for an explanation how to download the data using R and gdal.
24 November 2020
12:39
Oslandia: (Fr) Oslandia recrute : ingénieur(e) développement C++ / Python – OSL2011B
sur Planet OSGeo

Sorry, this entry is only available in French.
23 November 2020
11:58
gvSIG Team: Novedades gvSIG Desktop 2.5.1: Buscador de herramientas
sur Planet OSGeo
Esta nueva funcionalidad, disponible en la versión recientemente publicada gvSIG Desktop 2.5.1, puede ser muy útil para ejecutar de forma rápida herramientas en gvSIG Desktop o localizar alguna que no sabemos exactamente dónde está.

Su funcionamiento es muy sencillo y os quedará muy claro viendo el vídeo que acompaña a este post. Una vez lanzado el buscador de herramientas, que podemos tener siempre abierto, podemos filtrar y seleccionar entre todas las herramientas disponibles en gvSIG Desktop.

¿Útil, verdad?

Para mostrar el funcionamiento he aplicado el juego de iconos «Black», al que muchos no estaréis acostumbrados, pues no es el estilo por defecto de gvSIG Desktop. Y siguiendo este ejemplo, he utilizado el buscador de herramientas para ir ejecutando diversas acciones: abrir tabla, lanzar el buscador alfanumérico, activar el botón de información,…

Otros post sobre las novedades de gvSIG Desktop 2.5.1:
10:52
GeoTools Team: GeoTools 24.1 released
sur Planet OSGeo

The GeoTools team is pleased to share the availability of GeoTools 24.1 :geotools-24.1-bin.zipgeotools-24.1-doc.zipgeotools-24.1-userguide.zipgeotools-24.1-project.zipThis release is published to the osgeo maven repository, and is made in conjunction with GeoServer 2.18.1. This is a stable release and is a recommended upgrade for all users of the GeoTools library.We would like to thank
1:00
GeoServer Team: GeoServer 2.18.1 Released
sur Planet OSGeo
We are pleased to announce the release of GeoServer 2.18.1 with downloads (war bin), documentation and extensions.

This release is made in conjunction with GeoTools 24.1 and GeoWebCache 1.18.1. This is a stable release recommended for production systems.

Thanks to everyone who contributed, and Alessandro Parma, Andrea Aime (GeoSolutions) for making this release.
Improvements and Fixes
This release includes a number of improvements. Notable improvements:
- New option allow to tile cache WMS requests that align to gridsets, even if tiled=true is not present.
- New process grouping features by attribute, and then selecting a single one out of the group, in particular, the feature with the min or max value of a given attribute. Can be used either as a rendering transformation or a stand-alone WPS process.
- GeoFence integrated UI allows to configure security rules by IP address ranges.
Fixes included in this release:
- Better WPS packaging, including the required CSV libraries.
- Better support for WMS XML post requests in workspace local services.
- Addressed incompatibility with macOS 11 preventing startup
For more information check the 2.18.1 release notes.
Community Updates
For developers building from source, our community modules are a great place to collaborate on functionality and improvements.
- The “feature template” module has received assorted improvements
About GeoServer 2.17
Additional information on GeoServer 2.18 series:
- State of GeoServer 2.18 (slides)
- GeoServer Orientation (slides|video)
- Release Notes (2.18.1 | 2.18.0 | 2.18-RC)
22 November 2020
14:51
From GIS to Remote Sensing: Major Update: Semi-Automatic Classification Plugin v. 7.1.0
sur Planet OSGeo

I'm glad to release a new update of the Semi-Automatic Classification Plugin v. 7.1.0. This is the first version after the first release 7.0 and includes several bug fixing for several tools, therefore I recommend to update the plugin to the latest version.
Also, a new feature allows to import the polygons in a GeoPackage vector directly to the training input calculating the spectral signature thereof.

For any comment or question, join the Facebook group about the Semi-Automatic Classification Plugin.
20 November 2020
17:23
gvSIG Team: Journées Internationales gvSIG 2020 – Présentation en français – Suite gvSIG : Solutions libres pour la gestion territoriale
sur Planet OSGeo

Lors des journées internationales gvSIG ( du 4 au 6 Novembre dernier) a été effectuée une présentation en français sur l’importance actuelle de la géomatique et des données géographiques, et sur les solutions pouvant être apportées par l’Association gvSIG concernant la gestion territoriale, au travers de la Suite gvSIG, composée d’un logiciel SIG corporatif (gvSIG Desktop), d’une plateforme intégrale pour l’intégration d’Infrastructures de Données Spatiales (gvSIG Online) et d’applications SIG mobiles (gvSIG Mobile et gvSIG MApps).

Voici le lien vers la vidéo de cette présentation !
8:50
gvSIG Team: Marco de topología en gvSIG Desktop y nuevas reglas topológicas
sur Planet OSGeo

En gvSIG Desktop 2.5.1 podéis acceder al marco de topología de gvSIG Desktop, una herramienta muy importante para realizar ciertos procesos de edición cartográfica. El marco de topología se está mejorando con la inclusión de nuevas reglas topológicas, y de todo eso se habla en la grabación de esta ponencia de las Jornadas Internacionales de gvSIG.

Si aún no conoces el marco de topología de gvSIG Desktop, es hora de descubrirlo.
1:00
PostGIS Development: PostGIS 3.0.3
sur Planet OSGeo

The PostGIS Team is pleased to release PostGIS 3.0.3.

Best served with PostgreSQL 13.1, and GEOS 3.8.1

pgRouting 3.1.1
Continue Reading by clicking title hyperlink ..
19 November 2020
21:00
Paul Ramsey: Waiting for Postgis 3.1: Vector tile improvements
sur Planet OSGeo

This is a guest post from Raúl Marín, a core PostGIS contributor and a former colleague of mine at Carto. Raúl is an amazing systems engineer and has been cruising through the PostGIS code base making things faster and more efficient. You can find the original of this post at his new personal tech blog. – Paul

I’m not big on creating new things, I would rather work on improving something that’s already in use and has proven its usefulness. So whenever I’m thinking about what I should do next I tend to look for projects or features that are widely used, where the balance between development and runtime costs favors a more in depth approach.

Upon reviewing the changes of the upcoming PostGIS 3.1 release, it shouldn’t come as a surprise then that most of my contributions are focused on performance. When in doubt, just make it faster.

Since CARTO, the company that pays for my lunch, uses PostGIS’ Vector Tile functions as its backend for dynamic vector maps, any improvement there will have a clear impact on the platform. This is why since the appearance of the MVT functions in PostGIS 2.4 they’ve been enhanced in each major release, and 3.1 wasn’t going to be any different.

In this occasion the main reason behind the changes wasn’t the usual me looking for trouble, but the other way around. As ST_AsMVT makes it really easy to extract information from the database and into the browser, a common pitfall is to use SELECT * to extract all available columns which might move a lot of data unnecessarily and generate extremely big tiles. The easy solution to this problem is to only select the properties needed for the visualization but it’s hard to apply it retroactively once the application is in production and already depending on the inefficient design.

So there I was, looking into why the OOM killer was stopping databases, and discovering queries using a massive amount of resources to generate tiles 50-100 times bigger than they should (the recommendation is smaller than 500 KB). And in this case, the bad design of extracting all columns from the dataset was worsened by the fact that is was being applied to a large dataset; this triggered PostgreSQL parallelism requiring extra resources to generate chunks in parallel and later merge them together. In PostGIS 3.1 I introduced several changes to improve the performance of these 2 steps: the parallel processing and the merge of intermediate results.
The changes
Without getting into too much detail, the main benefit comes from changing the vector tile .proto such that a feature can only hold one value at a time. This is what the specification says, but not what the .proto enforces, therefore the internal library was allocating memory that it never used.

There are other additional changes, such as improving how values are merged between parallel workers, so feel free to have a look at the final commit itself if you want more details.
Performance comparison
The best way to see the impact of these changes is through some examples. In both cases I am generating the same tile, in the same exact server and with the same dependencies; the only change was to replace the PostGIS library, which in 3.0 to 3.1 doesn’t require an upgrade.

In the first example the tile contains all the columns of the 287k points in it. As I’ve mentioned before, it is discouraged to do this, but it is the simplest query to generate.

And for the second example, I’m generating the same tile but now only including the minimal columns for the visualization:

We can see, both in 3.0 and 3.1, that adding only the necessary properties makes things 10 times as fast as with the full data, and also that Postgis 3.1 is 30-40% faster in both situations.
Memory usage
Aside from speed, this change also greatly reduces the amount of memory used to generate a tile.

To see it in action, we monitor the PostgreSQL process while it’s generating the tile with all the properties. In 3.0, we observe in the blue line that the memory usage increases with time until it reaches around 2.7 GB at the end of the transaction.

We now monitor the same request on a server using Postgis 3.1. In this case the server uses around a third of the memory as in 3.0 (1GB vs 2.7GB) and, instead of having a linear increase, the memory is returned back to the system as soon as possible.

To sum it all up: PostGIS 3.1 is faster and uses less memory when generating large vector tiles.
20:00
MapProxy: New MapProxy 1.13.0 release
sur Planet OSGeo
We are pleased to announce the release of MapProxy 1.13.0.

The latest release is available at: [https:]]

To upgrade within your virtualenv:
```
$ pip install --upgrade --no-deps MapProxy
```
Updated documentation is available at: [https:]]
Some of the improvements
MapProxy is now able to use the latest PROJ releases via pyproj.

You can hide the source URLs in WMS exceptions with the new globals [http.hide_exception_url] option.

Tile sources can contain @ characters in the path of the URL (e.g. for HiDPI tile URLs like /0/0/0@2x.png).
Other fixes and changes
There are a lot more changes and improvements, especially regarding Python 3.8 compatibility.

For a complete list of see: [github.com]
16:03
Fernando Quadro: Série: Como desenvolver seu WebGIS
sur Planet OSGeo

Prezados leitores,

No mês de outubro e novembro produzi a série intitulada “Como desenvolver seu WebGIS” com o intuito de elucidar alguns pontos referentes a escolha de ferramentas (open source) para tal fim.

A série está disponível no canal do YouTube da Geocursos e foi dividida em 6 episódios:

1. Banco de dados espacial

2. Servidor de mapas

3. Backend

4. Frontend

5. Desktop GIS

6. Dados
12:47
gvSIG Team: Taller disponible: Normalización radiométrica e índices de vegetación en mapeo de incendios con gvSIG
sur Planet OSGeo
Ya tenéis disponible la grabación del taller «Normalización radiométrica e índices de vegetación en mapeo de incendios», que fue impartido en las pasadas Jornadas Internacionales gvSIG.

En el taller se trabaja con un método de normalización, mediante la sustracción de píxeles oscuros basado en el histograma de la imagen. Se utilizan imágenes Sentinel 2 de la Agencia Espacial Europea (ESA) con la siguiente secuencia o flujo de trabajo:
- Preprocesamiento de las imágenes
  - Transformación a formato tif de las bandas
  - Reasignación de los valores No Data
  - Conversión a valores enteros de 16 bits
- Procesamiento o calibración a valores de reflectancia
- Sustracción del píxel oscuro
- Generación de índices de vegetación.
La cartografía para poder seguir el taller puede descargarse en el siguiente enlace.

Grabación del taller:
10:40
gvSIG Team: Disponible el programa de las Jornadas GeoLIBERO (online) con inscripciones gratuitas
sur Planet OSGeo

Ya está disponible el programa de las 1as Jornadas Iberoamericanas GeoLIBERO. ¡Y no te las puedes perder!

Las jornadas que se celebrarán del 23 al 27 de noviembre son online, permitiendo a cualquier persona interesada acceder a cualquiera de las actividades que contempla el evento: ponencias, talleres y una interesantísima mesa redonda sobre ética y datos geográficos.

Las inscripciones son gratuitas y pueden realizarse para cada webinar desde la página web del programa del evento.

Estas Jornadas están organizadas por GeoLIBERO, una Red CYTED, formada por cerca de un centenar de investigadores, cuyo objetivo es consolidar y hacer sostenible en el tiempo una red temática de intercambio de conocimientos y de cooperación entre diferentes grupos de I+D+i de la región Iberoamericana relacionados con el ámbito de la Geomática y su aplicación a las necesidades y estudio de los problemas principales en Iberoamérica. Todo ello trabajando con software libre, impulsando la soberanía tecnológica de la región, y maximizando la transferencia tecnológica y de conocimiento.
9:21
gvSIG Team: gvSIG en cálculo de riesgos de inundación y prevención de incendios
sur Planet OSGeo

La Suite gvSIG se utiliza en los más diversos sectores, siendo aquellos que están relacionados con la seguridad y emergencias algunos de los más relevantes por las implicaciones que tienen. Entidades como la Dirección General de Emergencias y Protección Civil de España o el Consorcio Provincial de Bomberos de Valencia utilizan gvSIG desde hace ya unos años.

Más allá de los grandes proyectos, hoy os traemos un par de ponencias muy interesantes presentadas en las pasadas Jornadas Internacionales de gvSIG y que cuentan como utilizar, de forma sencilla, la Suite gvSIG tanto para el cálculo del riesgo de inundación como para la gestión de datos e infraestructuras de prevención de incendios.

gvSIG como herramienta auxiliar para el cálculo del riesgo de inundación

Suite gvSIG para gestión de datos e infraestructuras de prevención de incendios
1:00
PostGIS Development: PostGIS 3.1.0alpha3
sur Planet OSGeo

The PostGIS Team is pleased to release the third alpha of upcoming PostGIS 3.1.0 release. This version is exposes some of the new performance and feature enhancements in not yet relesed GEOS 3.9 as well as numerous speed enhancements not requiring newer GEOS. Requires GEOS 3.6+ and PostgreSQL 9.6+. To use MVT you will need protobuf-c 1.1. or higher.

Best served with

PostgreSQL 13.1, GEOS 3.7 or higher is recommended.

pgRouting 3.1.1
Continue Reading by clicking title hyperlink ..
18 November 2020
10:32
XYCarto: Static Vector Tiles for Small Projects
sur Planet OSGeo
The following covers a method for visualizing a complex vector tile dataset using a static server. This particular blog is more for beginners and reduces the technical terms as much as possible. I wouldn’t recommend this method for large complex vector tile data sets, but instead for quick one-off sites that are looking to incorporate a small number of vector tiles where the GeoJSON might be too large/complex to handle.

If you just want to skip to the map and code, visit the Github page created for this blog.

Here is the big reveal at the beginning. If you want to serve a basic vector tile locally or with a static server:
1. Create an tile cache with uncompressed .pbf files
2. Place that tile cache on something like GitPages, e.g. embed the tile cache directly along with your website or embed the cache on your localhost along with the other site files
3. In Leaflet, access the tile cache using ‘L.vectorGrid.protobuf()’
If you’d like to read more in depth:

I work on a Ubuntu OS; however, the methods below will just as easily work with iOS and Windows environments. The parts for building the site, e.g. the HTML, JS, CSS and GitPages, are OS agnostic.

If you want to follow the steps outlined you will need to have installed:
- GDAL: I am only including this since I used GDAL to extract the contours from the original elevation file.
- OGR2OGR: Easy tool for converting your shapefile to GeoJSON.
- Tippecanoe: Excellent tool for generating your tile caches in Web Mercator.
- T-Rex: Necessary for building your tile cache in a custom projection like NZTM. I tried a number of methods and T-Rex seemed to work best. Sadly, as of Nov 2020, ogr2ogr cannot currently create an MVT in NZTM projection, but it can do projections where the resolutions are halved at each zoom level.
- Leaflet: Your friendly JS library for building your map in a web environment.
- SimpleHTTPServer:">[httpserver">SimpleHTTPServer:] if you’d like to do localhost testing, you can run your site with this.
You will also need a Github account and a basic knowledge of building a webpage .

Here are the two stacks depending on your needs:
- Web Mercator: GDAL, OGR2OGR, Tippecanoe, Leaflet, GitPages
- NZTM: GDAL, OGR2OGR, PostGIS, T-Rex, Leaflet, GitPages
The basic premise is this: with your vector file, you need to construct a tile cache with uncompressed PBF files. The tile cache is the same as any XYZ tile cache you would use for raster tiles, except you are filling it with .pbf files. That tile cache will need to reside in a location accessible by your Leaflet application. In this example we are using GitPages as our server and embedding our tiles directly along with the website we built. Technically, Gitpages is acting as the server. If you are testing and serving on localhost, just embed your tile cache with your web files.

I am going to keep the code light for this blog and instead layout the steps. You can find full code examples in my Github repository here.

Building Your Own Contours

Download Elevation in NZTM
[https:]]

If you download the entire dataset, you can create the contour lines from the VRT. This saves a lot of time by not creating a mosaic.

Build VRT
```
gdalbuildvrt dem.vrt *.tif
```
Contour (@ 50m intervals)
```
gdal_contour -a elev -i 50 dem.vrt wellyDEMContour.shp
```
Web Mercator Tile Cache

If you are building a Web Mercator site, you can use Tippecanoe to render the tile cache. You need to create a GeoJSON of your shapefile first

Shape to GeoJSON
```
ogr2ogr -f GeoJSON -a_srs EPSG:2193 -t_srs EPSG:3857 wellyDEMContour.json wellyDEMContour.shp
```
Tile JSON
```
tippecanoe --no-tile-compression --projection=EPSG:3857 --minimum-zoom=12 --maximum-zoom=16 --output-to-directory "static.vector.tiles/contoursWebmer" wellyDEMContour.json
```
NZTM Tile Cache

If you are building an NZTM site you will need to use T-Rex to generate the NZTM tile cache for the vector tiles. T-Rex likes best if you can give it a PostGIS table to work from. I’d also recommend simplifying complex contour data sets. Your tile generation will be much faster.

Upload to PostgreSQL (you can upload the original NZTM shapefile)
```
shp2pgsql -s 2193 wellyDEMContour_NZTM.shp public.contournztm | psql -h localhost -d dbName -U userName
```
T-Rex Config

See full config here

Note the tile size you are setting. You will need this later for your Leaflet application
```
[grid.user]
width = 4096
height = 4096
extent = { minx = -1000000, miny = 3087000, maxx = 3327000, maxy = 10000000 }
srid = 2193
units = "m"
resolutions = [8960.0,4480.0,2240.0,1120.0,560.0,280.0,140.0,70.0,28.0,14.0,7.0,2.8,1.4,0.7,0.28,0.14,0.07]
origin = "TopLeft"
```
T-Rex Tile Cache
```
t_rex generate --progress true --maxzoom=12 --minzoom=9 --extent=160.6,-55.95,-171.2,-25.88 --config /static.vector.tiles/trexConfig/configpsql_contour.toml
```
Decompress PBF Files
```
find . -type f | xargs -n1 -P 1 -t -I % gzip -d -r -S .pbf %
find . -type f | xargs -n1 -P 1 -t -I % % %.pbf
```
Important bit for Leaflet

See the GitPages site for how to set up the Leaflet JS in NZTM
```
// Access the tile cache
var vector = L.vectorGrid.protobuf(vectorURL, styles);
```
Have fun!
10:01
Jackie Ng: Experimental Azure PaaS support in the SQL Server FDO provider
sur Planet OSGeo

Do you use MapGuide? Do you also use SQL Server on Azure and have lamented for the longest time the inability of the SQL Server FDO provider to read/write data to a Azure-PaaS-hosted SQL Server db?
Then boy, do I have news for you!
Thanks to some day-job dogfooding of FDO Toolbox and a test Azure account on hand I have finally tackled this 7 year old FDO ticket and landed experimental support for SQL Server on Azure PaaS.
You can download the 7zip archive of the patched provider from here.
Download, extract and overwrite the existing provider dll in your MapGuide Open Source 4.0 preview or FDO Toolbox 1.5.1 installation.
I have so far verified this provider can perform most provider operations needed for use in a MapGuide context.
The only operation I couldn't verify was whether the FDO CreateDataStore API worked for this provider in Azure PaaS due to insufficient permissions in the test account I was given. The CreateDataStore API is not used in the MapGuide context, so if this API doesn't work properly on Azure PaaS, it is not a deal breaker for use in MapGuide.
I'd be interested from anyone who tries this patched provider to let me know if this particular API works on Azure PaaS (ie. You can create a new FDO data store on Azure PaaS via FDO Toolbox with this patched provider)
Many thanks to Crispin Hoult of TrueViewVisuals (FKA LinkNode) for the original patch, which I had tweaked so the azure db detection is a runtime check instead of support you have to explicitly compile into the provider dll. If we had been using Azure PaaS earlier, the patch wouldn't have taken 7 years to finally be applied!
10:00
CARTO Blog: 7 Reasons Why CPG Marketers Are Turning To Location Analytics
sur Planet OSGeo

Think about this time last year and ask yourself these questions: Has your office location changed? Are you or your family living in a different location? Are you shopping...

Skip to page: 1 2 3 ... 12

← Blogs GeoRezo.net

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Carte des membres Sites amis	Agenda Biblio Netvibes Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Carte des CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Num Pts	Randomized	In Order
10K	126 ms	341 ms
20K	172 ms	1924 ms
50K	417 ms	12.3 s
100K	1030 ms	59 s
200K	1729 ms	240 s
500K	5354 ms	Overflow

Le portail francophone de la géomatique

Feeds

Autres planets