I think a simplified GIS program with stripped-down functionality and an intuitive UI could be a big hit. Think of SketchUp versus SolidWorks or ProE.
Here's a couple maps that I have made about the Honoulu marathon that I wouldn't have made in a more complex/time-intensive piece/powerful piece of software: - https://felt.com/map/UNOFFICIAL-Honolulu-Marathon-2022-TCg9C... - https://felt.com/map/UNOFFICIAL-Honolulu-Marathon-2022-Road-...
Or to put it another way, what's the workflow that a simpler, more opinionated interface would solve, and what features could or would you sacrifice for it?
- A lot of people come to it wanting to edit or annotate existing city/street maps with geometry, like you're describing.
- My first encounters with it were trying to plot points on a map to build a heat map, in a data analysis context, and I was coming from Google Earth/KML.
- The next time, I wanted to georeference raster maps to make more accurate vector data, and I was coming from Inkscape and Illustrator.
- Another popular use case is to work with topographical and height data, which is another workflow with mostly another interface in QGIS.
- And all of these can have very different output goals - slippy maps with raster or vector tiles, topo maps, 3D renderings and prints, GeoJSON and PostGIS data.
The "most obvious" app for each of those use cases would each be different, with different interfaces. And I can see where that would be good for beginners, or for limited use cases, but at some point each of those use cases intersects with another. Drawing bike lanes on a map quickly means working with topo data. Georeferencing a new base map eventually hits plotting POIs and drawing things like political borders as geometry. Outputting a heat map from data you plot in QGIS can work, but then you need to plug it into a database at some point so the data can be updated in a shared or automated context.
IMO what would be more useful for QGIS is a ground-up, no-assumptions review of its UI similar to what Blender did in 2.8/3.0. Find where they can consolidate redundant or conflicting tools and interfaces, redesign their mouse/keyboard interactions and tool palettes around how users intuit they should work, and provide alternate modes for the more complex workflows that existing users are accustomed to. Blender's redesign proved pretty well that an esoteric UI can be streamlined and modernized without sacrificing power user workflows.
But I don't know if the QGIS UI community is as large, organized, or focused on modern UI design as Blender's, which was a rather unique case in FLOSS. And it'd be difficult to divorce QGIS's GIS data-editing engine from its interface as a whole to build standalone tools with smaller UIs focused on tasks instead of toolboxes.
Plugins might be able to do this, which could be an interesting approach. Instead of adding features like plugins tend to do, one could ship a "flavor" of QGIS with pre-installed and -configured plugins that provide narrower, task-focused interfaces around existing features.
You likely either: - needed to export an image of the data (raster); - needed to digitise the data within; - needed to extract the vector data first from the pdf and work out how to deal with it.
Opening a pdf without appropriate data structures into a gis software package is akin to taking a picture of a billboard that has a printed image of a map on it and then expecting to be able to do anything with that picture. The pdf is a bit better, but not by much unless it began life as a georeferenced pdf with vector data maintained.
By the time I got it, it was just a vector image.
The infrastructure in question was pipelines, represented in the PDF by lines, so georeferencing them was enough to get spatial data adequate for the application.
These two already dominate more casual mapping