I didn't make a sandwich today, but I found another sandwich photo on my phone. This one is from January, when I was working through a large batch of homemade red cabbage (with apple and carrot) kimchi.
Pastrami, red cabbage kimchi, and swiss cheese on rye
La dernière version maintenue à long terme (LTR) de QGIS est la version 3.22. La première version corrective de 3.22 ayant ce statut est la version 3.22.4 publiée fin février 2022.
Cette version est importante pour les utilisateurs et la communauté de développeurs car elle sera maintenue jusqu'en février 2023. Elle a aussi été testée pendant 3 mois avant d'obtenir le statut LTR qui est un gage de stabilité et de qualité.
Voici la liste des contributions de 3Liz pour cette version 3.22 de QGIS (incluant 3.18 et 3.20)
qgis_process et qgis_mapserverLa plupart des fonctionnalités ont été financées par l'Ifremer, ou par certains clients utilisant notre solution d'hébergement Lizmap et ayant un problème avec QGIS Server, ou sur notre temps Open Source à 3Liz.
The latest long-term released (LTR) version of QGIS is 3.22. The first bugfix release of 3.22 with this status is version 3.22.4 released in late February 2022.
This version is important for users and the developer community as it will be maintained until February 2023. It was also tested for 3 months before obtaining the LTR status which is a guarantee of stability and quality.
Here is the list of 3Liz contributions for this QGIS 3.22 release (including 3.18 and 3.20)
qgis_process and qgis_mapserver.Most of the features were funded by Ifremer, or by some customers using our Lizmap hosting solution and having a problem with QGIS Server, or on our Open Source time at 3Liz.
Ruth is traveling all next week and I will be busy holding down the fort and going to end-of-year school activities. Forgive me if I'm slow to reply to emails and open source issues and pull requests.
Here are the numbers for week seven.
10 hours, 7 minutes
50 miles
5564 ft D+
Six days of running in a row, two speed workouts, and back-to-back weekend long runs. Next week is a rest week with less running and more biking, yoga, and weight lifting.
I stopped by King Soopers after my long run to get a few groceries. Do you ever, because you're ravenously hungry, buy things you didn't know you needed until you see them? I brought home some liverwurst and made a sandwich of it.
Liverwurst, pepper jack, red onion, pickle, whole grain mustard, on sourdough bread
Eating this reminds of driving from Logan (Utah) to Salt Lake City with my family to have Sunday dinners with my dad's parents and grandparents. The older Gillieses and Clines almost always had liverwurst and crackers for an appetizer. I don't remember ever disliking it.
You must be logged into the site to view this content.
Ci siamo, l’anno 2021 è finito da un po’ e sto scrivendo la lista dei libri che ho letto. Questa lista è dedicata a due persone che mi hanno detto di averla letta negli anni scorsi, A. e M.
Quest’anno ho tenuto traccia dei libri letti e desiderati in un modo nuovo, su un nodo BookWyrm. Ho pensato che avrei potuto leggere 12 libri e ne ho letti 12, ma più che la quantità mi ha dato soddisfazione la continuità. Sono anche riuscito a leggere più lentamente, a rileggere lunghi capitoli e persino un libro intero perché avevo la sensazione di averli letti troppo in fretta.
Avevamo lasciato il nostro lettore alle prese con Seni e uova.
Ho impiegato diversi mesi a leggere “Seni e uova”. È un libro monumentale, non solo per le dimensioni.
Cosa vuol dire nascere, cosa vuol dire diventare donna ed esserlo, cosa vuol dire diventare madre, cosa vuol dire diventare padre. Sono tutte domande a cui ho pensato leggendo questo libro.
E poi, anche come si fa a scrivere libri ‒ questo è un altro dei tanti fili che legano le pagine dall’inizio alla fine.
I dialoghi di “Seni e uova” sono più che scambi di parole. Ognuno trova il modo di dire tutto quello che ha da dire, e lo fa in modo straripante, e paralizza essere di fronte a questi lunghi discorsi dove i punti di vista vengono costruiti in modo dettagliato, feroce e liberatorio.
Questa è una lettura che mi era stata consigliata due anni fa nel fediverso. Breve, tagliente e diretto, il resoconto di come Scheherazade si sia annacquata mentre veniva trasportata ad Occidente (Scheherazade goes West, è il titolo originale), come una eroina si sia trasformata in una macchietta di pensierini insulsi nella testa degli uomini bianchi.
Come mi sono promesso, ho continuato la lettura della saga, mi sono immerso nel mondo di Terramare e ho trasportato di qua e di là il librone che lo contiene praticamente tutto. Che meraviglia. Ogni libro è una storia dall’inizio alla fine e vive di vita propria, ma i fili che legano luoghi e persone sono lunghi e profondi.
Questo è il libro della saga che ho trovato più cupo, nonostante Le tombe di Atuan si svolga in gran parte sottoterra. Al centro dell’apoteosi di Ged e della nascita di una nuova guida per Terramare c’è un rapporto di fiducia che è messo in difficoltà e in dubbio dai due protagonisti. E questo è molto più inquietante di una caverna oscura o dell’aldilà.
Quando ho iniziato a leggere questo libro ho finalmente capito che Le Guin ha dato una forma di alternanza alle parti della saga, maschile, femminile, maschile, femminile. Questo libro è molto femminile: segue Tenar come protagonista, sia nelle gesta eroiche sia in quelle più semplici nella casa e nella campagna. Tenar salva la piccola Therru, la vittima di una orribile violenza che rimane a lungo traumatizzata, e anche questo è drammaticamente femminile. Finale epico.
L’ultima parte che conclude la saga è di trasfigurazione. Ho letto due volte il libro perché la prima lettura era stata troppo frettolosa, e perché volevo seguire bene il viaggio dei protagonisti. Una storia che inizia con una brocca rotta non può che catturarmi, d’altra parte. Ho fatto un po’ fatica a seguire con attenzione i nomi dei vari Maestri, e ho confuso un po’ il Maestro delle Mani e quello dei Modelli. Sorrido pensando a come viene sconfitta la Morte qui con una vaga reminescenza del finale un po’ ridicolo del Cannocchiale d’ambra (che non rileggerei affatto).
La raccolta è proprio quello che ci si aspetta per dare spazio alla costruzione del mondo di Terramare. Funziona tutto molto bene, le mie storie preferite qui sono state quelle di Lontra/Medra e di Libellula (che in lingua originale è più direttamente evocativo della protagonista).
I personaggi sono piuttosto inquietanti nel loro delirio reciproco, e il modo in cui Lloyd stesso deve ancora una volta seguire istinti fuori dalle regole è particolarmente ben sviluppato.
“Heaven” è appena uscito, il nuovo libro di Mieko Kawakami.
Non è stato facile leggere “Heaven” perché è un romanzo veramente molto diretto e mi ha buttato dentro alcune tematiche che faccio molta fatica ad affrontare serenamente, come il suicidio, la fiducia negli altri, chiudersi in se stessi. Pur essendo molto più breve del precedente romanzo ne ripropone lo stile grandioso, i lunghi mono-dialoghi in cui alcuni personaggi espongono nei minimi dettagli tutto quello che pensano di un determinato argomento, spesso in modo brutale. La mia memoria di alcuni episodi e periodi di bullismo scolastico, ben più leggero di quello affrontato dai protagonisti, è ancora viva. Qui invece andiamo proprio dentro il quotidiano dentro la testa di chi subisce, e per un po’ anche dentro quella di chi massacra gli altri. È molto duro e c’è una parte di violenza quasi grafica. Non conosco abbastanza la cultura né la letteratura giapponese per situare “Heaven” rispetto a questo tema.
Ho voluto finire di leggerlo durante un pomeriggio soleggiato, sul divano, invece che prima di addormentarmi la sera. Ma sono contento di averlo letto.
Che noia. Ripetitivo allo sfinimento, nostalgico di quando si faceva il militare, maschilista.
Questo l’ho trovato per caso e mi è piaciuto, un po’ letteratura di genere e un po’ spiazzante e onesto sguardo sulla solitudine, sulla salute mentale.
Questo era nella lista dei libri da leggere almeno da due anni. Divorato in modo abbastanza spietato e all’altezza delle aspettative. Per favore non mi parlate di serie TV.
Nel 2022 ho continuato a leggere Elena Ferrante.
Week six was a productive one with four days of running. One tough speed workout, a tempo run in the hills, and one long run along the first ridge on the east edge of the Rocky Mountains. Here are the numbers.
7 hours, 42 minutes running
37.5 miles
4396 ft D+
Saturday I helped at Quad Rock. I transported drop bags from the starting line to the Horsetooth aid station (miles 10 and 40) and then spent 12 hours at the aid station with a stint of watching a tricky trail intersection a mile upstream.
Starting line, 5:15 a.m.
Horsetooth aid station, 6:40 a.m.
Mid-day it was warm, about 85° F (30° C). Every runner coming into the aid station a second time looked overheated to some degree, and still had one final climb to go with much of it in full sun. We cooled them down; put ice in water bottles, bandanas, hats; and handed out popsicles. It was super satisfying to see energy and smiles come back to the runners. According to OpenSplitTime, everyone who left our aid station finished. We had one person drop and 4 who didn't make the time cut.
After the trail sweepers came in from the previous station, I helped pack up, and then transported drop bags and the DNF runners to the finish.
Rain fell early Sunday. I waited for it to stop and then went out for an extremely easy 15-mile trail run bracketed by 3-mile bike rides from and to home. I saw lots of kids hiking with their moms.
Finally a hint of green
GeoServer 2.21-RC release is now available with downloads (bin, war, windows), along with docs and extensions.
This is a GeoServer release candidate made in conjunction with GeoTools 27-RC and GeoWebCache 1.21-RC.
We would like to ask for your assistance testing the following:
Try out the new language chooser, and if you spot any translations you can help out with we would love your assistance translating geoserver.
The ability to customize feature types allows for a lot of creativity, please try this out and share your examples
This release features a new Log4J logging system. If you only choose between the built-in logging profiles we expect everything to be smooth an uneventful.
If you have made any custom logging profiles, or customized the built-in logging profiles in place, some additional care is required (see below). We are very interested in this upgrade process and ask for your feedback and testing at this time.
For those using GDAL or OGR please check the instructions below on upgrading to GDAL 3.
A reminder that open-source is a community activity and we ask everyone to take part at this time.
We are pleased to share a long-requested feature - the ability to rename attributes and change attribute order when publishing a FeatureType.
It is also possible to change attribute type, and with the use of ECQL expressions generate new attributes on the fly.
The above example works around the limitations of shapefile to use longer names, and creates a new attribute capital on the fly from an expression, as shown in the following GetFeatureInfo output.
This is a great new addition to GeoServer, please see Feture Type Details in the user guide for details.
Thanks to Andrea Aime (GeoSolutions) for proposal GSIP-207 and implementation.
A big thanks to Alexandre Gacon and everyone who helped improve GeoServer internationalization for during this release cycle.
To support this activity Andrea Aime has contributed a language chooser to the top of the screen (near the login button).
For more information see Choosing the UI language (User Guide).
Layer groups can now be configured with additional styles, with each style listing a series of layers along with the style used to render each layer.
This allows a SINGLE or OPAQUE layer group to list alternate styles in addition to the default one. Each alternate style is defined by a named configuration of layers and styles providing a unique visual representation.
In the above example the layer group Tasmania is setup with an alternate “data” presentation, presenting the content with the geoserver default styles point, line and polygon.
For more information see Layer Group Styles (User Guide).
Thanks to Marco Volpini (GeoSolutions) for GSIP-205 proposal and implementation.
The result of proposal GSIP-206 is the creation of the gs-geopkg-output extension packaging up the WFS and WMS output formats from the geopackage community module.
curl "http://localhost:8080/geoserver/wfs?service=wfs&version=2.0.0&request=GetFeature&typeNames=topp:states&outputFormat=geopkg" -o wfs.gpkg
For more information see Using the GeoPackage Output Extension in the user guide.
Thanks to David Blasby and Jody Garnett (GeoCat) for packaging up this work as an extension.
When rendering maps with lots of individual graphics, looking up the correct implementation (known as a MarkFactory) can be time consuming.
WMS Settings have new capability to filter out any mark factories not being used, and provide an order to prioritise the ones being used.
For more information see WMS Web Administration (user guide).
Thanks to Fernando Mino (GeoSolutions Group) for troubleshooting this performance issue, and proposal GSIP-205 as an optimization.
The assessment of Log4Shell vulnerability highlighted that although GeoSever was not affected, our use of the older Log4j 1.2 was a notable risk. This discussion resulted a small fundraising effort and proposal to upgrade to Log4j 2.
The result is a small change to the user interface, listing logging profiles by name (previously the file extension was also listed).
Internally this release replaces changes from Log4j 1.2 logging profiles (using properties extension) to Log4j 2 logging profiles (using xml extension):
The built-in logging profiles (DEFAULT_LOGGING, PRODUCTION_LOGGING, …) are replaced with new Log4j 2 xml files.
Previous custom logging profiles will continue to be available (Log4J 2 has the ability to read the older Log4J 1.2 properties files).
If you made any customizations to the built-in profiles, you can recover your changes from backup bak file. You can use this backup as a reference when creating a new xml logging profile, or restore this under a different name which does not conflict with the built-in logging profiles.
A customization to PRODUCTION_LOGGING.properties will be backed up to PRODUCTION_LOGGING.properties.bak. This can be restored by renaming PRODUCTION_LOGGING.properties.bak to CUSTOM_LOGGING.properties.
In addition to the INFO status messages, you will notice a new CONFIG logging level used during application startup:
CONFIG [org.geoserver] - GeoServer configuration lock is enabled
CONFIG [org.geoserver] - Loading catalog...
...
For more information, and examples of writing on log4J 2 profile, see Logging Settings and Advanced log configuration in the User Guide. Of note is the introduction of a new CONFIG logging level used loading and saving configuration changes.
Thanks to Jody Garnett (GeoCat) for completing this work, and to the following sponsors for supporting this activity.
For more information please see Logging settings (User Guide) and GeoServer Logging (REST API).
Thanks to Yalın Eren Deliorman for this contribution.
A number of improvements have been made to the WPS service:
GEOS-10443 Graduate kml-ppio community module to wps extension
KML can now be used with WPS service for both input and output parameters.
GEOS-10391 Add external output directory setting to limit where processes can write
See WPS setting for external output directory in User Guide.
GEOS-10431 Add WPS setting to disable remote complex inputs.
See WPS Security and input limits in User Guide.
The gdal-output extension is tested against GDAL 3.x series.
Please pay careful attention to the installation instructions, while the extensions includes gdal-3.2.0.jar you should double check the native binaries (included in your Linux distribution or installed by hand) and download an appropriate replacement jar online.
For more information see Installing GDAL native libraries in the User Guide.
Thanks to Andrea Aime (GeoSolutions) for making the ImageIO-EXT release, and Jody Garnett (GeoCat) for GDAL 3.x upgrade and testing.
New features:
Improvements:
Fixes:
Tasks:
Additional information on GeoServer 2.21 series:
Release notes: ( 2.21-RC )
You must be logged into the site to view this content.
The electrons were hardly dry on the JTS Outer and Inner Polygon Hull post when another interesting use case popped up on GIS StackExchange. The question was how to remove aliasing artifacts (AKA "jaggies") from polygons created by vectorizing raster data, with the condition that the result should contain the original polygon.
A polygon for Vancouver Island vectorized from a coarse raster dataset. Aliasing artifacts are obvious.
This problem is often handled by applying a simplification or smoothing process to the "jaggy" polygon boundary. This works, as long as the process preserves polygonal topology (e.g. such as the JTS TopologyPreservingSimplifier). But generally this output of this process does not contain the input polygon, since the simplification/smoothing can alter the boundary inwards as well as outwards.
In contrast, the JTS Polygon Outer Hull algorithm is designed to do exactly what is required: it reduces the number of vertices, while guaranteeing that the input polygon is contained in the result. It is essentially a simplification method which also preserves polygonal topology (using an area-based approach similar to the Visvalingham-Whyatt algorithm).
Here's a real-world example, taken from the GADM dataset for administrative areas of Germany. The coastline of the state of Mecklenburg-Vorpommern appears to have been derived from a raster, and thus exhibits aliasing artifacts. Computing the outer hull with a fairly conservative parameter eliminates most of the artifacts, and ensures polygonal topology is preserved.
A potential issue for using Outer Hull as a smoothing technique is the choice of parameter value controlling the amount of change. The algorithm provides two options: the ratio of reduction in the number of vertices, or the fraction of change in area allowed. Both of these are scale-independent, and reflect natural goals for controlling simplification. But neither relate directly to the goal of removing "stairstep" artifacts along the boundary. This might be better specified via a distance-based parameter. The parameter value could then be determined based on the known artifact size (i.e. the resolution of the underlying grid). Since the algorithm for Outer Hull is quite flexible, this should be feasible to implement.
Today, I’m revisiting work from 2017. In Brezina, Graser & Leth (2017), we looked at different ways to determine the width of sidewalks in Vienna based on the city’s street surface database.
Image source: Brezina, Graser & Leth (2017)Inscribed and circumscribed circles were a natural starting point. Circumscribed or bounding circle tools (the smallest circle to enclose an input polygon) have been commonly available in desktop GIS and spatial databases. Inscribed circle tools (the largest circle that fits into an input polygon) used to be less readily available. Lately, support has improved since ST_MaximumInscribedCircle has been added in PostGIS 3.1.0 (requires GEOS >= 3.9.0).
The tricky thing is that ST_MaximumInscribedCircle does not behave like ST_MinimumBoundingCircle. While the bounding circle function returns the circle geometry, the inscribed circle function returns a record containing information on the circle center and radius. Handling the resulting records involves some not so intuitive SQL.
Here is what I’ve come up with to get both the circle geometries as well as the radius values:
WITH foo AS
(
SELECT id,
ST_MaximumInscribedCircle(geom) AS inscribed_circle,
ST_MinimumBoundingRadius(geom) AS bounding_circle
FROM demo.sidewalks
)
SELECT
id,
(bounding_circle).radius AS bounding_circle_radius,
ST_MinimumBoundingCircle(geom) AS bounding_circle_geom,
(inscribed_circle).radius AS inscribed_circle_radius,
ST_Buffer((inscribed_circle).center, (inscribed_circle).radius) AS inscribed_circle_geom
FROM foo
And here is how the results look like in QGIS, with purple shapeburst fills for bounding circles and green shapeburst fills for inscribed circles:
References
Our last OSGeo “Code Sprint” event in Bolsena – Italy was in 2019. And this year we are back! The code sprint is planned for an extended period of 10 days, giving all that participate a chance to work and meet a little bit longer. The event in Bolsena is in an Italian monastery (see map location), photos and videos: 2008-video, 2009-video and 2010-video. The monastery is overlooking Lago Bolsena and offers space to about 25 people in small bedrooms 🙂 . It is one of the coolest places for such an event. Quiet, isolated, simple and serene.
Have a look yourself, including looking at the photo gallery. For what the food concerns, we cook elaborate meals you will definitely enjoy 🙂 . There’s a large dining space, but we will eat outside overlooking the lake if weather permits (very likely in June). You can stay all ten days and food (breakfast, lunch and dinner) is included in the price. As in previous years, we will go out for a city visit and a dinner on one of the evenings.
The event will take place during the whole week, although the emphasis will probably be Monday to Friday for most participants.
More information on the OSGeo wiki.
The post Bolsena Code Sprint 2022 appeared first on GeoCat B.V..
Dry and windy weather continues here on Colorado's Front Range. I'm not a big fan of running in mud, but we really need some steady, soaking rain here. This dry and desiccating spring is unusual and is challenging our drought-tolerant environment. Many plants are still semi-dormant and the landscape is still mostly a midwinter yellow-brown color and flowers are slow to appear. One exception is the white blossom of the tough-as-nails sand lily (Leucocrinum montanum). This plant is in full bloom locally, as plentiful as ever. I was surprised to learn today that sand lilies are in the same family as asparagus. I saw one clematis blossom in a wetter spot this week, and a few bluebells here and there. In other years, these are erupting everywhere.
Here are the numbers for week five. Season highs all around. I'll go double this distance and 2.5 times the time and climbing one week in July.
8 hours, 35 minutes
43 miles
6010 ft D+
Six days of running, my first substantial speed workout, and two runs with plenty of hills. I'm mostly hiking up the hills and trying to flow down them without braking. In a few weeks I'll start to push it more on the ascents. 5 minute uphill intervals with 1 minute of recovery do amazing things for my fitness.
Saturday, May 7, I will be volunteering all day for the Quad Rock race and will you see you if you pass through the Horsetooth aid station. It's at the 10 and 40 mile marks for the race courses. I'm looking forward to helping you 25 milers settle into the middle of your course and helping you 50 milers get the fuel and what you need for your finish.
The JTS Topology Suite recently gained the ability to compute concave hulls. The Concave Hull algorithm computes a polygon enclosing a set of points using a parameter to determine the "tightness". However, for polygonal inputs the computed concave hull does not always respect the polygon boundaries. So the concave hull may not actually contain the input polygon.
It would be useful to be able to compute the "outer concave hull" of a polygon. This is a valid polygon formed by a subset of the vertices of the input polygon which fully contains the input polygon. Vertices can be eliminated as long as the resulting boundary does not self-intersect, and does not cross into the original polygon.
An outer concave hull of a polygon representing Switzerland
As with point-set concave hulls, the vertex reduction is controlled by a numeric parameter. This creates a sequence of hulls of increasingly larger area with smaller vertex counts. At an extreme value of the parameter, the outer hull is the same as the convex hull of the input.
The outer hull concept extends to handle holes and MultiPolygons. In all cases the hull boundaries are constructed so that they do not cross each other, thus ensuring the validity of the result.
An outer hull of a MultiPolygon for the coast of Denmark. The hull polygons do not cross.
It's also possible to construct inner hulls of polygons, where the constructed hull is fully within the original polygon.
Inner hulls also support holes and MultiPolygons. At an extreme value of the control parameter, holes become convex hulls, and a polygon shell reduces to a triangle (unless blocked by the presence of holes).
A hull can provide a significant reduction in the vertex size of a polygon for a minimal change in area. This could allow faster evaluation of spatial predicates, by pre-filtering with smaller hulls of polygons.
An outer hull of Brazil provides a 10x reduction in vertex size, with only ~1% change in area.
This has been on the JTS To-Do list for a while (I first proposed it back in 2009). At that time it was presented as a way of simplifying polygonal geometry. Of course JTS has had the TopologyPreservingSimplifier for many years. But it doesn't compute a strictly outer hull. Also, it's based on Douglas-Peucker simplification, which isn't ideal for polygons.
It seems there's quite a need for this functionality, as shown in these GIS-StackExchange posts (1, 2, 3, 4). There's even existing implementations on Github: rdp-expansion-only and simplipy (both in Python) - but both of these sound like they have some significant issues.
Recent JTS R&D (on concave hulls and polygon triangulation) has provided the basis for an effective, performant polygonal concave hull algorithm. This is now released as the PolygonHull class in JTS.
Polygon hulls have the following characteristics:
The PolygonHull algorithm supports computing both outer and inner hulls.
The number of vertices removed is controlled by a numeric parameter. Two different parameters are provided:
The algorithm removes vertices via "corner clipping". Corners are triangles formed by three consecutive vertices in a (current) boundary ring of a polygon. Corners are removed when they meet certain criteria. For an outer hull, a corner can be removed if it is concave (for shell rings) or convex (for hole rings). For an inner hull the removable corner orientations are reversed.
In both variants, corners are removed only if the triangle they form does not contain other vertices of the (current) boundary rings. This condition prevents self-intersections from occurring within or between rings. This ensures the resulting hull geometry is topologically valid. Detecting triangle-vertex intersections is made performant by maintaining a spatial index on the vertices in the rings. This is supported by an index structure called a VertexSequencePackedRtree. This is a semi-static R-tree built on the list of vertices of each polygon boundary ring. Vertex lists typically have a high degree of spatial coherency, so the constructed R-tree generally provides good space utilization. It provides fast bounding-box search, and supports item removal (allowing the index to stay consistent as ring vertices are removed).
Corners that are candidates for removal are kept in a priority queue ordered by area. Corners are removed in order of smallest area first. This minimizes the amount of change for a given vertex count, and produces a better quality result. Removing a corner may create new corners, which are inserted in the priority queue for processing. Corners in the queue may be invalidated if one of the corner side vertices has previously been removed; invalid corners are discarded.
This algorithm uses techniques originated for the Ear-Clipping approach used in the JTS PolgyonTriangulator implementation. It also has a similarity to the Visvalingham-Whyatt simplification algorithm. But as far as I know using this approach for computing outer and inner hulls is novel. (After the fact I found a recent paper about a similar construction called a Shortcut Hull [Bonerath et al 2020], but it uses a different approach).
It should be straightforward to use this same approach to implement a Topology-Preserving Simplifier variant using the corner-area-removal approach (as in Visvalingham-Whyatt simplification). The result would be a simplified, topologically-valid polygonal geometry. The simplification parameter limits the number of result vertices directly, or the net change in area. The resulting shape should be a good approximation of the input, but would not necessarily be either wholly inside or outside.
I have the day off work today. After saying goodbye to my mother-in-law, who has been visiting, and making lunches for my kids, I drove to Lory State Park for a very nice, hilly trail run (7.75 miles, 1876 ft D+, average grade 4.4% including downhills). I listened to the new King Gizzard & the Lizard Wizard double album, Omnium Gatherum, on the drive and laughed out loud a few times. It's so good. And self-indulgent, which is exactly my mood today.
It's important to refuel after a hard run, so when I got home I made an extra loaded, extra buttery, grilled Cubano-ish sandwich. Did you know the Lucerne cheese company is selling ghost pepper jack? When I saw it in the store I had to grab it. Honestly, it could be hotter.
Black Forest ham, ghost pepper jack, red onion, dill pickle, and mustard on white bread.
Última atualização 2021-12-10 20:18:19.
Pessoal:Os últimos meses foram corridos, me descuidei e desde janeiro que não posto nada aqui no blog. Alguns fatos que aconteceram nesse tempo:
Profissional:Houve mudanças no ambiente de trabalho, mudei de setor e agora tenho mais responsabilidades. Hoje estou numa posição de gestão, o que me afastou da parte técnica do setor de GEO.
Comunidade:Estou participando do comitê geral do FOSS4G 2022, que irá acontecer em Florença-Itália, mais informações no site oficial do evento.
Leitura:Li o livro ONDE MORREM OS AVIÕES, do Lito Sousa do canal: aviões e música.
Nota de transparência: os links dos livros acima têm código de afiliado. Clicando neles, os preços não mudam, mas posso ganhar uma comissão da Amazon.
Assistindo:Do que assistir destaco o documentário Downfall: The Case Against Boeing interessante documentário sobre os incidentes envolvendo o Boeing 737 MAX.
De filmes assisti The Highwaymen, filme da Netflix sobre a caçada ao casal de ladrões Bonnie e Clyde. Ainda sobre no tema policial indico a série The Great Robbery of Brazil’s Central Bank que narra os fatos do assalto ao banco central de Fortaleza. Outro filme que assisti foi Gemini Man e não recomendo.
No momento estou acompanhando Better Call Saul: Season 6 , para mim a melhor série do momento. Também estou assistindo Moon Knight .
Ouvindo:Não consigo indicar outra coisa a não ser o podcast Mano a Mano, original Spotify com Mano Brown. De fato um programa que me fez ampliar a visão e o debate trazendo diversidade de ideias e pensamentos com profundidade e respeito.
“Minha alucinação é suportar o dia a dia, e o meu delírio é a experiência com coisas reais.”
— Belchior
The post Abril / 2022 appeared first on Narcélio de Sá.
In week three I did six consecutive days of running. Track intervals on Wednesday. Singletrack tempo on Thursday. Back-to-back 2+ hour runs Saturday and Sunday. The weather was cool and windy and I fought with a sinus infection for motivation. Happily, 30 minutes of running never failed to make me feel better.
7 hours, 58 minutes
40.5 miles
5262 ft D+
Half of my week four training was in San Francisco. Tuesday I went along the Embarcadero and up the Filbert Steps to the Coit Tower on Telegraph Hill. Wednesday I went to Christmas Tree Point on the north summit (922 ft) of the Twin Peaks via Corona Heights.
5 hours, 8 minutes
28.3 miles
2854 ft D+
Downtown San Francisco from Corona Heights
The little peak of Corona Heights is made out of chert, a dense and glassy rock. A quarry has uncovered an unusually large section of rock polished by fault motion. Geologists call this a slickenside. I saw a coyote at the base of the hill. I've seen signs warning about them around the city before, but this was the first time I've seen a coyote in San Francisco. Tom MacWright gave Corona Heights a 5 for its views. The view of the city and bay is great, but there's no view of the ocean, so I might give it a 4.8.
I concur with Tom's 6/5 score for running at Twin Peaks. The access from the north, at least, is still car free. There's a longish 8% grade that is super satisfying to finish. I try to make it up there every time I visit San Francisco.
The PostGIS Team is pleased to release PostGIS 2.4.10! This is the end-of-life release of the 2.4 branch.
2.4.10
This release is a bug fix release, addressing issues found in the previous 2.4 releases.
Since last week’s post, I’ve learned that there is an official OGC Moving Features JSON Encodings repository with more recent sample datasets, including MovingPoint, MovingPolygon, and Trajectory JSON examples.
The MovingPoint example seems to describe a storm, including its path (temporalGeometry), pressure, wind strength, and class values (temporalProperties):
You can give the current implementation a spin using this MyBinder notebook
An exciting future step would be to experiment with extending MovingPandas to support the MovingPolygon MF-JSON examples. MovingPolygons can change their size and orientation as they move. I’m not yet sure, however, if the number of polygon nodes can change between time steps and how this would be reflected by the prism concept presented in the draft specification:
Image source: https://ksookim.github.io/mf-json/
This is a guest post by Mickael HOARAU @Oneil974
As an update of the tutorial from previous years, I created a tutorial showing how to make a simple and dynamic color map with charts in QGIS.
In this tutorial you can see some of interesting features of QGIS and its community plugins. Here you’ll see variables, expressions, filters, QuickOSM and DataPlotly plugins and much more. You just need to use QGIS 3.24 Tisler version.
Here is the tutorial.
Since I got the basic sanity checking PHP script running without crashing, there was one problem remaining around MgByteReader contents being read incorrectly. This turned out to be another out-of-date SWIG typemap around byte arrays. Once that got fixed we are able to read out the contents of the MgByteReader without content corruption. This is an important thing to test because a lot of results from the MapGuide API (XML results, rendered map images, map plots, etc) come in the form of MgByteReaders. If we can't read content out of these readers without data corruption we have major problems, but that is fortunately not the case (so far!).
With that out of the way, it was onto to the current PHP test suite for the MapGuide API and getting it fixed up and passing.
But before we go there, I wanted to check if our new PHP binding was leaking memory in the most obvious cases. To that effect, I built our PHP binding with reference counting diagnostics enabled and wrote this PHP script.
1 | <?php |
1 | xdebug.mode = debug |
by Jackie Ng (noreply@blogger.com) at April 21, 2022 04:21 PM
The PostGIS Team is pleased to release PostGIS 2.5.6!
2.5.6
This release is a bug fix release, addressing issues found in the previous 2.5 releases.
Over a year ago Chris Holmes, the driving force behind the “cloud optimized GeoTIFF” (COG) and “spatio-temporal asset catalog” (STAC) standards that are sweeping the “cloud optimized raster” data management world, asked me what I thought the story of a similar “cloud optimized vector” format might look like.
And I thought about COG, which is really just a very very old format (GeoTIFF) with its bytes rearranged so that the order of bytes in the file matches the likely order in which they will be accessed (blocks of bands, and within the bands, squares of pixels), and I thought I had the perfect, maximally snarky answer:
Dude, shape file is already a cloud-native format.
Now, this might seem counter-intuitive, but hear me out:
In short, shapefile already looks a lot like GeoTIFF, the founding format of the “cloud optimized geospatial” movement.
So, what is missing to make “cloud optimized shapefile” a reality?
Well, in order to spatially search a shapefile you need a spatial index. There is no index format in the formal Esri specification, and the Esri sbx index format is proprietary (though largely reverse engineered at this point) but the open source world has had a shape file index format for 20 years: the “QIX file”.
You generate a QIX file using the shptree utility in Mapserver. You can also generate one in GDAL. You can also get GeoTools to generate one.
With a QIX file, the “shape file” now consists of four files:
The next trick, just as in COG, is to put the main data files (shp, dbf and shx) into the same order they are likely to be searched in: spatial order.
Since we already have a spatial index (qix), we can get the files in spatial order by re-writing them in the same order they appear in the index.
Initially I told Chris that this could be done with the Mapserver sortshp utility, however I was mistaken: sortshp sorts the file in attribute order.
To make “cloud optimized shape file” a reality, first we need a new utility program that sorts the shp, shx and dbf files into qix order.
We need: coshp!
coshp is just a re-working of the sortshp utility, but instead of sorting the output file by attribute it sorts it using the index tree as the driver. This results in shp and dbf files where shapes that are “near” in space are also “near” in the byte-stream of the file. This will reduce the number of random reads necessary to access portions of the file using a bounding box search.
One of the quiet secrets of the “cloud optimized” geospatial world is that, while all the attention is placed on the formats, the actual really really hard part is writing the clients that can efficiently make use of the carefully organized bytes.
For example, the fancy demonstrations of “pure client-side” COG browsers require a complete GeoTIFF reader in Javascript, along with some extra “cloud” smarts to know what pieces of data to cache and what to treat as transient info during rendering.
So, spatially sorting a shape file is a necessary, but not at all sufficient condition to create an actual “cloud optimized shapefile”, because for it to be practically useful, there needs to be at a minimum a client-side javascript reader.
That means javascript that can:
To be truly useful, the javascript should probably include enough cloud smarts to read and opportunistically cache pieces of the files: headers at a minimum, but also reading in branches of the qix and shx indexes on-demand.
To make things marginally easier, I have “documented” the QIX format. It’s an ugly beast, but it is possible to traverse it without deserializing the whole thing.
It’s a challenging problem, but I hope there is someone with enough nostalgia for old formats and thirst for glory to make it happen.
Recently I have gotten back into the grind of MapGuide development pushing to clear the final hurdle of having functional PHP bindings for the MapGuide API.
Since I last touched this code, several things have changed.
1 | <?php |
by Jackie Ng (noreply@blogger.com) at April 19, 2022 04:30 PM