We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Mapserver layer handling, production, and management in larger scale environment

00:00

Formale Metadaten

Titel
Mapserver layer handling, production, and management in larger scale environment
Serientitel
Anzahl der Teile
351
Autor
Mitwirkende
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache
Produktionsjahr2022

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Managing hundreds of layers from different sources in a Mapserver production is extensive work. Keeping them up to date, scalable and in constant deployment takes time and effort. Not to mention monitoring all of it. By combining a configuration management tool (open-source Progress Chef in our case) and Mapserver, we have a continues deployment cycle. Mapserver’s map file is divided into pieces that Chef puts together. All the layer files are separate entities which are easily manageable and changeable. Different map files can be produced combining different layers to keep map files smaller but still all in one place for management. It also enables to switch off or turn on layers easily. This also gives the benefit of keeping development environment different from production. Through MapProxy seeding process we also provided our thousands of users with their base map services and serve them WMS, WFS and our own produced Vectortiles. All of it is also under constants monitoring and the logs are processed to produce simple statistics to see which applications are requesting, which layers are being accessed the most. We have built a notification system that notifies us immediately through hooks if our services are down or there are errors in any of the Mapserver layers requests. It brings us back to the point of how to make your Mapserver layer handling, production, and management smoother and more straightforward. Let us share our insight!
Schlagwörter
Innerer PunktClientClientGamecontrollerMAPKonfiguration <Informatik>MultiplikationsoperatorElektronische PublikationDienst <Informatik>Selbst organisierendes SystemDifferenteMetadatenProdukt <Mathematik>MereologieSoftwareentwicklerProzessautomationCodeVersionsverwaltungMathematikKonfigurationsraumServerAnalytische FortsetzungGrenzschichtablösungBitComputersicherheitRahmenproblemMapping <Computergraphik>CASE <Informatik>Bildgebendes VerfahrenSoftwaretestDokumentenserverVisualisierungSymboltabelleComputeranimationXML
Transkript: Englisch(automatisch erzeugt)
Hi, my name is Sander. I am a GIS developer from the IT and Development Center at the Estonia Ministry of Interior. The name is long and not very telling. We provide GIS solutions for our public safety and security organizations like the police, rescue services, border guard and the like. For example, our services include geogoding, routing,
basemaps and the topic of my talk, map layers. As most spatial data users, our clients wanted to see something, visualize stuff. Technology-wise, we had two options at the time, GeoServer or MapServer, we chose MapServer. And as with everything, things grow, clients wanted
to see more stuff and see different layers. At first, we had a pretty basic map file. Every layer was in this one map file, quite static in its concept. But as more layers
were needed and different layers got integrated into different clients' development cycles, a need for version control arise. Basically, we needed better control over our production. We use a server continuous configuration automation tool called Chef Automate.
One part of the automation is building different MapServer map files. In our case, we hold every layer each in their own layer file. Chef takes all the needed MapServer metadata part, then all the layers that are configured for that map file,
and then all the symbols, puts it together and creates a map file. And it's continuously updated in a certain time frame, we use one hour. And through Chef, all of that is versioned and trackable, and it gives us all the control we need over our production.
By keeping the layers in separate layer files, we can create the different map files, smaller map files easily using Chef. It helps us keep it more client-based, gives us the flexibility, and is overall just a little bit more cleaner to maintain and manage the smaller map files. Also, some years ago, we did some light testing,
and we found that smaller map files performed better than bigger map files with more layers. But let's say everything is all up and running, or is it? Here, monitoring comes in. Besides the regular, is the server running? We actually check the data as well. Every layer is checked once in an hour if it returns a WMS image,
and then WFS check is done to see if any actual data and features are returned. And all of that is linked into our internal chat, so if something goes wrong, we are notified instantly. And as always, it never ends. We can easily add layers,
remove them, change styling, and through version controlling, it's really easy to manage with low effort. Unfortunately, we can't really show any code in public repositories, but if you come and ask us, we can actually show what we're doing. Thank you.