[dead]
Anatomy of a MapServer: how to leverage and visualize your geographical data
11–20 of 20 posts
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#12[flagged]
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#13Interesting. I've been very interested lately in autonomous mapping and localization. It looks like many of the base implementation problems have been solved in a way that is extensible enough that I'll be able to use the solutions.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#14Another common alternative to GeoServer and MapServer is QGIS Server. Based on THE Open Source Desktop GIS - QGIS Server publishes a QGIS project file as a WMS/WFS/WMT-S/OGC API service. From a visualization point of view, you have the advantage that the styling you have done in QGIS is reproduced 1:1, since QGIS Server uses the same rendering engine. Serializing the mapfiles from pydantic models as described by the author seems pretty cool though. I've tried this for QGIS project files as well, which are basically just XML files... but it gets tedious after a while.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#15This might not be obvious to anyone who doesn't work in mapping, but the technology stack they're describing (WMS) is generating images of mapping data which is sent to the browser, as opposed to sending actual data.
This solution was common 10 years ago but has largely been replaced by the alternative of vector tiles, in which data is sent to the browser and rendered there. That tends to give better performance and allow more interactive visualisations.
Hard to say for sure whether that kind of solution would have worked for them here, but it's quite odd to see such old technology written up as if it was the latest thing.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#16I am a novice at GIS and mapping but when I got started I thought a map/tile server was the only way to build mapping webapps. But, in my admittedly simple application PMTiles can cover a lot of my visualization use cases with a thin Django app doing GEOJson for interactive layers. https://github.com/protomaps/PMTiles
Wow, thanks! I checked and PMTiles is even supported in Maplibre. [1] This can probably replace 30% of online maps with static sources. [1]: https://maplibre.org/maplibre-gl-js/docs/examples/pmtiles/
The problem I found with pmtiles is not many servers support the required HTTP attributes. You need to carefully assess ahead of time.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#17Earlier quoted context omitted.
Wow, thanks! I checked and PMTiles is even supported in Maplibre. [1] This can probably replace 30% of online maps with static sources. [1]: https://maplibre.org/maplibre-gl-js/docs/examples/pmtiles/
The problem I found with pmtiles is not many servers support the required HTTP attributes. You need to carefully assess ahead of time.
I believe it's only range requests you need supported. there's also cool sqlite querying and flatgeobufs that can do fancy lookups on large single file formats
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#18This might not be obvious to anyone who doesn't work in mapping, but the technology stack they're describing (WMS) is generating images of mapping data which is sent to the browser, as opposed to sending actual data. This solution was common 10 years ago but has largely been replaced by the alternative of vector tiles, in which data is sent to the browser and rendered there. That tends to give better performance and…
at this point, you're explaining a parallel old is new type of devoantion
raster tiles have a specific size, but can't easily be tendered on demand.
vector tiles can be infinitely precise but can end up transferring way more data.
of course, whenever there's clear tradeoffs between techs, the modern gurus will vacilate between them, as the average programmer doesn't do the discriminate evaluation to pick the best tech, but what's popular.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#19Earlier quoted context omitted.
The problem I found with pmtiles is not many servers support the required HTTP attributes. You need to carefully assess ahead of time.
I believe it's only range requests you need supported. there's also cool sqlite querying and flatgeobufs that can do fancy lookups on large single file formats
Yeah. I don't know exactly how widely supported range requests are - my first few attempts turned up a few duds.
Re: Anatomy of a MapServer: how to leverage and visualize your geographical data
#20This might not be obvious to anyone who doesn't work in mapping, but the technology stack they're describing (WMS) is generating images of mapping data which is sent to the browser, as opposed to sending actual data. This solution was common 10 years ago but has largely been replaced by the alternative of vector tiles, in which data is sent to the browser and rendered there. That tends to give better performance and…
at this point, you're explaining a parallel old is new type of devoantion raster tiles have a specific size, but can't easily be tendered on demand. vector tiles can be infinitely precise but can end up transferring way more data. of course, whenever there's clear tradeoffs between techs, the modern gurus will vacilate between them, as the average programmer doesn't do the discriminate evaluation to pick the best tec…
>vector tiles can be infinitely precise but can end up transferring way more data.
"way more" - not likely, if it's an apples to apples comparison. Obviously there are extreme cases where tons of data is being shipped to the frontend that is not being used for anything.
The big advantage of vector tiles in practice is not needing any kind of tile rendering server in the background. You just generate your vector tiles (quick) then serve them straight up (easy). Simpler architecture and lower costs.