Implementing open source GIS

Work list (short)

In plain language, write down why you want open source (for example: less dependence on one vendor, easier links to other systems, or more control over data). Decide how far you want to go: maps on the PC only, maps on intranet or website as well, or a broader map-and-data setup.

• Involve the right people early: business (geo), IT, privacy/security if relevant, and someone who knows your contracts.
• Name processes that really cannot slip (permits, crisis, citizen desk). You wait longer with those or build a safe parallel path.
• Make success concrete: for example “20 colleagues work independently in QGIS” or “the map layer is ready automatically every night”.

Work list (short)

Make a simple list: which programs and contracts, where map files live, who makes maps, and who helps when something breaks. That quickly shows where it hurts.

• For each important map layer: who owns it, how often it must be refreshed, and whether you may share the data (licence and privacy).
• What other systems connect to it? Think of reports, case systems, organisation sign-in, or maps on phones for field staff.
• Briefly note what feels messy: old scripts, loose files, missing documentation. That usually decides what you tackle first.

Work list (short)

You do not have to replace everything at once. Many teams start with QGIS and a central place for map data; online maps for colleagues and citizens come later. Choose what fits your people and IT agreements, and what you can maintain.

• Discuss where software runs: on your servers, with a vendor in the cloud, or a mix. Think about backups and who applies updates.
• Keep test and production separate: try first, then roll out. A short written runbook prevents panic when something goes wrong.
• A hybrid route is normal: open source on the desktop and a commercial web platform (such as GeoApps) for sharing, sign-in, and links, or the other way around.

Work list (short)

Open source brings freedom and responsibility: who may do what, which passwords must never be shared, and how do you back up? Agree this with IT and privacy, so no one has to guess later.

• Who tracks security notices for the products you use, and how quickly do you patch?
• Keep a simple rule for which QGIS (or other) plugins are allowed, so people do not install unknown add-ons blindly.
• Make clear who helps users when something breaks: service desk, GIS team, or a partner.

Work list (short)

Pick one concrete example (one map product or one workflow). Train the people who will run it, and show them where to ask questions. If it works, you expand.

• Agree what “good enough” means: map speed, data correctness, availability outside office hours.
• Brief managers and colleagues in plain language: less jargon, more real examples.
• Unsure between “build everything yourself” and a ready-made web platform? Read our open source vs commercial piece and GeoApps vs QGIS.

Work list (short)

Converting old files often takes longer than installing new software. Work in small steps, spot-check boundaries and labels, and record who keeps the “right” version.

• Watch coordinate systems: one agreed rule for converting “old” to “new” so layers do not drift apart.
• A short note per layer (where it comes from, may I share it?) helps colleagues and prevents mistakes later.
• Track versions: which export belongs to which moment, especially when several people work in parallel.

Work list (short)

Open standards make it easier to switch vendors later or share data. In the Netherlands you often use national feeds (such as PDOK); note where they fit and who owns them.

• Put map URLs and sign-in details for each service in one place, so people do not reinvent the wheel.
• If you load many external maps: agree whether you may cache them briefly to avoid overload.

Work list (short)

Software ages: plan once a year (or more) which versions you upgrade and how you roll back if something breaks. Small regular care prevents big crises.

• One page of “what do I if…” (blank map, full disk, expired certificate) saves hours in incidents.
• Open source lives on communities; occasionally spending time on docs or a bug report helps everyone.