Lat × Long Homepage

Deck.gl v8.9 introduces interesting new features:

  • OGC Web Map Service (WMS) layers (Yes, they still exist),
  • A terrain extension allows developers to render 2D data on a 3D surface, and
  • Collision filters, hiding overlapping features and resulting in cleaner visualisation of dense data.

Deck.gl doesn’t get much recognition, but it looks like a serious web-mapping toolkit.

The market for open-source web-map libraries is getting crowded again. Some classic libraries are still around: OpenLayers, Leaflet, and MapboxGL (technically not open-source). With MapLibre, Gleo, and Deck.gl, some promising new implementations are on the rise. Technology-wise, map front-ends have stalled in the last couple of years. I hope this newfound competition results in advancements in the field.

Mapstack

Mapstack, launched this week, aims to become a central catalogue for open data, a place where you discover and access datasets to fulfil your geo-data needs:

mapstack will do for open map data what GitHub did for open source, by bringing all of the world’s open maps together in one place and making them easy to discover, easy to access and easy to use.

Most of Mapstack’s functionality is currently centred around creating datasets and providing appropriate descriptions for the data. Setting up a new map involves several steps, including creating a new workspace or team, adding members, and providing a description.

Then you proceed to create the actual dataset. Upload your data, currently limited to GeoJSON and files smaller than 50MB. Then select the fields to keep and provide human-readable names. A downside is that you can’t skip this step. You have to go through each chosen field and individually confirm the label. To finalise, provide more information about the nature of the data, its geographic area, and the feature type, which creates an editable name for your new dataset.

That’s a lot of steps before you can view your dataset for the first time. Much of the information can be done after the project is set up. With the goal of discoverability in mind, however, and considering how badly many datasets are missing meta-data, you could say it’s smart design to force users to provide context.

Once the map is created, the features are limited: You can browse the data, view the attribute of features, and apply filters. There’s an attribute table, which is only available for filtered results, but not for the unfiltered data. Mapstack focuses on hosting data and making the data discoverable rather than on interacting, editing or visualising data.

As such, Mapstack is not a competitor of Felt or Placemark, two products released last year that aim to modernise how we do GIS on the Web. Mapstack complements both, and GIS tooling in general, by providing the data for the tools.

Will it take off? I’m not sure. The marketing copy draws comparisons to GitHub, but there are differences. GitHub became successful because it built on a protocol that developers already used and provided a product for collaboration around the protocol. GitHub added value to the developer’s daily work, so a lot of code ended up on the platform.

Mapstack doesn’t tie in with existing tools. Currently, there is no tooling to create or manage data, collaborate or visualise the data. It’s a place where the result of data processing might be hosted. Open data providers have invested in the infrastructure to host data—it’ll be hard to convince them to migrate to Mapstack instead.

Geospatial Projects at Google Summer of Code 2023

The mentor organisations for this year’s Google Summer of Code have been announced. Amongst other open-source household names, Google Summer of Code 2023 features various organisations and projects from the geospatial world, including:

Google Summer of Code is an internship program which pays aspiring software developers to contribute to open-source projects for three months during the summer. The application phase for this year’s cohort of interns opens on 20 March and closes on 4 April.

Say what you want about Google, but you have to appreciate their ongoing commitment to open-source software and their efforts to connect young programmers with projects.

For a recent story, instead of Mapbox, The Post used OpenMapTiles, Maputnik, PMTiles, and MapLibre to produce interactive web maps.

Kevin Schaul:

For some projects, I’m sure we’ll continue using Mapbox. But for most of our use cases, we don’t need the latest and greatest. And Mapbox has gotten expensive.

Planet has published a library of React components to build map user interfaces using OpenLayers:

The @planet/maps library provides components for rendering maps in your React applications. The library acts as a wrapper around OpenLayers, transforming the imperative API into declarative components.

The design goals:

The purpose of this project is to provide a mapping between React’s declarative components and OpenLayers’ imperative API. In other words, this project provides a React renderer for OpenLayers.

[…]

  • Components exported by this package map 1:1 with classes exported by OpenLayers.
  • Component props map directly to properties that are settable on instances of OpenLayers classes. Exceptions to this are props like options (passed to the constructor only), listener props (e.g. onChange), and ref.
  • Components accept a ref that provide access to the underlying OpenLayers instance.

The examples only show a small fraction of the whole feature set of the library. I looked through the source code on GitHub, and it seems like many—if not all—OpenLayers classes have a corresponding React component in the library.

Circles are only supported in a few geo-data formats because most of today’s formats are based on the Simple Features specification, which doesn’t define circles.

Tom MacWright, writing on the Placemark blog, explores why circles are so hard to implement into geo-data applications and why Placemark ended up with three circle definitions: geodesic, degree and Mercator circles.

Tom MacWright, after joining val.town, reflects on building Placemark. It’s an honest account of what it’s like to build and grow a business—something we don’t see very often.

Placemark will live, but in what form isn’t entirely clear:

I’ve envisioned it as a tool that you can use for simple things but can grow into a tool you use professionally or semi-professionally, but maybe that’s not the future: the future is Canva, not Illustrator.

I’ve been wondering how the announcement of Felt, which happened around the same time as Placemark’s, would affect Placemark’s future. Felt has venture capital, a team of smart people, and a lot of buzz, whilst Placemark is a bootstrapped one-man show.

Fiona, the Python library for reading and writing features from and to various data sources, has a new release. From the release notes:

The major new features are:

  • A new CRS class identical to Rasterio’s.
  • New Feature and Geometry classes. These are returned instead of dicts but are compatible with version 1.8’s dicts. _ Access to format driver metadata.

Wheels of the new release are also available for M1 Macs now.

Seek-Optimized ZIP (SOZip)

Seek-Optimized ZIP, a new profile for ZIP files, allows random access and selective decompression. With standard ZIP files, you have to download and decompress the ZIP file before accessing its content. While fully compatible with standard ZIP tools, with SOZip, you can now selectively access files within a ZIP, so you won’t have to download the full archive if you want to access just one file.

Currently, there are two implementations for SOZip: It’s available in the development branch GDAL and as a Python module. MapServer (on the development branch) and QGIS, both applications depending on GDAL, support SOZip too.

Seek-Optimized ZIP file adds to a growing suite of cloud-native data formats and APIs, such as COGs, Zarr or GeoParquet, allowing developers and applications to access and process large selectively without the need to download complete datasets.

Related Links

FlatGeobuf on its Way to Become OGC Community Standard

The FlatGeobuf community has started the process to formally adopt the specification as an OGC Community Standard. (A document linked by Bert Temme on Twitter, providing reasoning for the spec to become a standard, is not publicly available anymore.)

FlatGeobuf provides binary encoding for geospatial vector data. It is lossless, streamable, enables random feature access, and is supported by a wide range of geospatial tools and libraries, including QGIS, GDAL, Fiona, and PostGIS.

OGC Community Standards are developed outside the more formal OGC standardisation process, usually by a group of individuals who also implement reference solutions (instead of panels of representatives from large organisations).

A quick tutorial by Bert Temme about how to turn a shape file into PMTiles using Tippecanoe:

 In this blog we created in a few easy steps vector tiles from shapefile of worldwide railroads in PMTile format using Tippecanoe, and deployed to a standard webserver. No complicated backend WMS/WFS mapservers are needed anymore to get this working.

How did we get to the point where there’s a need for a consortium aiming to standardise road map data? And what motivates big names like AWS, Microsoft, Meta, and TomTom to join forces?

James Killick has answers: Several providers are all building their own version of the same product leading to a fractured landscape for map data. Some providers are now looking to lower the cost of producing their data, assert control over how open data is created, and improve interoperability between data sources.

Registration for FOSSGIS 2023, the German-speaking FOSS4G event, is now open. The conference will be held from 15 to 18 March 2023 in Berlin, Germany.

If you need convincing to attend, the conference schedule is also available. The program features a mix of developer updates, case studies, and practical applications of open-source software and OpenStreetMap, as well as a series of hands-on workshops diving into the latest and greatest open-source software for geospatial.

James Killick on the problem of geodata standardisation:

The lack of common, broadly adopted geospatial data exchange standards is crippling the geospatial industry. It’s a bit like going to an EV charger with your shiny new electric vehicle and discovering you can’t charge it because your car has a different connector to the one used by the EV charger. The electricity is there and ready to be sucked up and used, but, sorry — your vehicle can’t consume it unless you miraculously come up with a magical adaptor that allows the energy to flow.

Standards exist for public-transport information but are missing for many other types of geodata. The commercial premise for these domains is different.

For public-transport organisations, their data is not the product. Trains and buses moving through a city are. Network and schedule data is a means to get more people to use public transport, so you want to get this information in front of as many people as possible—through displays on stations, a website or third-party applications. And you want to integrate with other transport authorities’ data to provide a seamless service. All this is best accomplished through shared interfaces and data models.

On the other hand, road-network and address data isn’t a vehicle to sell a product; it usually is the product. You license it because you offer a service (delivery, navigation) that requires this information. The companies providing that data often survey and maintain the data themselves. The idea that you could swap out or merge their data with someone else’s using the routines and data models you already build is a threat to that business model. They don’t want interoperability; they want lock-in, so you keep paying them, not somebody else.

Iván Sánchez Ortega reporting from his activities during the latest OGC code sprint:

when pygeoapi is requested a coverage from GIS client (preferring image/tiff or application/ld+json or the like), the raw data is returned. But when it’s a web browser (preferring text/html), then a webpage with a small viewer is returned.

It’s an interesting deep-dive into HTTP content negotiation, how it relates to geo-data problems and what OGC API implementations could do better.