I tried to draw a map for a polygon-type geographical feature set parsed from a GeoJSON file. Converting the spatial polygons to Typst polygons is very simple. The only effort I made is a very basic affine transformation from geographical coordinates to page coordinates.
However, there is still a long way to go, even the very goal is only drawing polygons rather than making a package for thematic maps. At least, the following elements are missing:
Compass
Scale bar
Legend
Title
Frame
CRS transformation
But I can see the power of creating maps within a typesetting software. If it is fully implemented, I can use ArcGIS, R, Python, and even other softwares to do analysis and build models and leave mapping for Typst. And the map would be editable when writing articles. I can adjust the title, legend, and other elements at any time, without opening other softwares and re-creating a figure.
Thanks for considering adding lq.geo. I’m quite looking forward to this feature. I’m also willing try to contribute some codes.
As for the GeoJSON, I have no much experience, neither. I participated in some WebGIS projects, in which GeoJSON files are loaded, interpreted, and rendered automatically by the 3rd-party libraries, like leaflet and ArcGIS API. Among all the geo-data formats, GeoJSON is the simplest and readable one. However, some ver important features, like the coordinate reference system (or known as projections), are not supported by GeoJSON. So I’m not sure whether GeoJSON is a good start point, although I start from it.
GeoJSON is used in this demo because it is exactly JSON. So Typst can parse the file and this saved me a huge amount of time on reading files. However, I wonder whether it is possible to support some other geo-data formats, like ESRI Shapefile (this would be the most useful one for GISers) and GeoPackage (based on Sqlite), via WASM plugins? These formats are more welcome than GeoJSON, as they have more powerful support for geographical data.
Or, it would be better if GDAL library is integrated to support all formats, including GeoJSON. But I’m worrying about the package’s size — GDAL could obviously increase the size of this package, slow down the loading speed, and also deviating the development work too far from the original intention of the lilaq package.
All of these are still waiting for your decision.
In addition, although I have learnt some knowledge of computer graphics many years ago, it is still far from sufficient to contribute a stable and usable mapping package. So perhaps those who specialise in the traditional GIS development field could offer better assistance and collaboration. Nevertheless, I will contribute within my capability.
Hi @Aegon ,
Thank you for your detailed answer. I will give it some thought. It sounds like adding GDAL via WASM is too much for Lilaq on its own. However, in the future this could be done with a third-party package. Instead, we could provide useful plotting functions within Lilaq that can be used through such a package, for example a function that plots a set of polygons. Each polygon could optionally be associated with a scalar number that may be mapped to a color by specifying a map (just like with lq.colormesh). And maybe a way to add patterns to the patches etc.
Applying advanced projections might be difficult if one also wants to show a corresponding curved coordinate grid. This would be something to address long-term but it is also desirable for plotting applications apart for geography. If a coordinate grid is not necessary, however, a third-party package could just preprocess the coordinates that are sent to Lilaq.
All in all, for Lilaq we could focus on providing nice and powerful primitives, the ability to add legend entries, color bars etc.
I think most of the specialized use cases for plotting geographical data can be achieved perfectly fine with ArcGIS and co, and probably most people would prefer using that tool and exporting the plot. More mundane usage like plotting some geoJSON data is a low enough hanging-fruit that I feel like it’s perfectly fine IMO to say that lilaq is only supporting that data format.
