Refactor the map view to not use a javascript approach

[hol430]

Resolves #5662
Resolves #5241
Relevant to #4381, #4333, maybe others

The new widget uses SharpMap. Generally it's a little more clunky than the old map view but it does work and should be more reliable for autodocs purposes. Panning/zooming with the mouse works ok. I've modified the installers, so that they install the necessary shapefiles. I've also added a converter which resets the center coordinates and zoom level of all map components to default values which make sense for the new map view.

[zur003]

Any reason not to use BruTile to let us pull in better base maps (e.g., from OpenStreetMap)?

[hol430]

No particular reason - it's a good idea. The api is pretty powerful and I haven't really explored much of it. I managed to get it working using a simple shapefile for testing and never ended up changing it.

[zur003]

@hol430 - I had a go at trying to use OpenStreetMap as the source for base maps. As is all too often the case, things didn't work quite as smoothly as hoped. For reasons I don't yet understand, the base maps appear to be retrieved, but aren't rendering. This is complicated somewhat by the version of SharpMap available via NuGet dating back to early 2014, even though the SharpMap code itself has had substantial (and on-going) revision since then. I'm not sure whether the old code never worked quite as intended, or OSM has changed in the intervening years. Here are some options:

1. Continue with the current crude mapping, which doesn't work very well at a local scale.
2. Try using an updated version of SharpMap (that is, build our own using the current source). This could probably be made to work, but at the cost of not being able to use NuGet to automatically pull in SharpMap with its dependencies. SharpMap itself pulls in stuff from a number of other toolkits, so it may be a bit fiddly to get everything set up nicely, and working across all platforms and frameworks.
3. Use the NuGet version of SharpMap, but try to come up with a work-around to get it working properly. We can easily get the source code for that version, so debugging is possible, but there's no guarantee a work-around will be possible.
4. Use a different tool for mapping. I've had a look at osm-gps-map, which provides a Gtk widget for the display of OSM maps, but it provides only a native platform .dll (or .so or .dylib), so we would need to generate a Gtk# wrapper to be able to use it. There's also the question of whether we could get it working with both Gtk#2 and Gtk#3 across all platforms.

Any thoughts about the best direction to take? Why are these things never simple or easy?

[hol430]

Hi Eric - thanks for looking into this. Agreed that it would be good to improve the current mapping implementation, as it is rather crude. I think I had some similar problems to you when I was getting this working in the netcore3 branch - the version in nuget was really outdated. I ended up compiling the latest source myself, and uploading it to my myget feed. I added this feed to the NuGet.config file on the netcore3 branch. I've used this approach for a couple of other packages which I've had to modify (OxyPlot.GtkSharp3, and, at one point, the gtksourceview package, although this is now available in nuget proper).

Depending on which exact revision of sharpmap you need, it may be possible to use a similar approach. I think the version on my myget feed targets .net standard 2.0, so in theory it may work on the main branch (although somehow I doubt it will be that simple :).