Maps rebuild over arching task list

brendanheywood commented 7 years ago

Ok lets recap the high level requirements that lots of people have asked for:

1) ability as consumer to swap from google maps to openstreet map / bing / etc 2) ability as guide editor to set preferred map as default for that crag 3) ability as guide editor to add points of interest to the map, in particular car parks and the walking track from the car park to the crag 4) as a user on a map be able to easily see a breakdown of gear style, and ideally but lower priority difficulty 5) as a user be able to search for stuff and have the map zoom out and find things just like google maps does

And on the technical side a variety of bugs / improvements: 6) change the algorithm for selecting what node we are 'in' given a bounding box 7) change the algorithm for selecting the label attachment point to fix bugs with 'banana' shaped crags where the label is outside the shape 8) we have the maps tab, we have the embedded map in list view, and we have the map editing page. All 3 are completely different code bases and have different pros and cons. At minimum we want the list view and the maps tab to be consistent, but ideally all 3

Going through each of these:

1) requires a generic map library, eg leaflet or openlayers 2) this is mostly on our side, but is dependent on 1) 3) we need new datamodels and api's for this. Isn't dependent on 1) but the editing tools are critical here so dependent on 8) 4) the main thing we need here is to be able to have full control over the labels and clusters we show on the map. I'm currently using an open source library for google maps for the clustering. This has a soft dependency on 1) as whatever framework we use, if we use one, need to give us this control 5) this is agnostic of js library. But we probably want to search not only our crag database but also search a generic location database such as the google maps reverse geosearch api 6) this is purely on our side, specced out and ready to go 7) specced out and ready to go. Doesn't matter what lib we use, as long as it gives us the fine grained control over the labels 8) mostly on our side

So I see this as a few stages which can be released separately:

STAGE 1: rebuild

URL routing:

[x] get leaflet lib loading google maps
[x] get map viewport with loading of map position base on coords and / or hash anchor (existing deep links need this)
[x] get hash tag updating as you pan
[x] if the zoom level start out (world level) then default to street map / terrain view, but if the zoom is local then default to satellite / aerial view

API

[x] create a new single api which given a bounding box and a resolution returns everything inside this box which should be visible (and a bit extra margin), ie a nested subtree of nodes going down until each node is too small to be useful (which is why we pass in a resolution)
[x] TO CONFIRM: every time we zoom or pan we ping that api again and then completely delete and set our internal state, however the api above should return a little bit more than it needs around then sides, so if we only scroll a little bit then we don't need a refresh. Note this is a big change from the current system which does a lot of caching at different layers, but the amount of data we are talking about is tiny. It's much simpler and robust to just refresh it and throw all the old state away. BUT ... this will work great for map tab deeplinks and also work really well in the embedded map in list view. The only place it may work badly and be heavy is when you are on the maps tab looking at the world before you zoom in. I think this will be ok but we just need to test and tune the resolution based cutoffs so we get a good spread of small clusters but not a massive ajax load. (fixes #2403, #1145, #421 )
[x] create a single template which renders both the big map in the maps tab, and the small embeded map in list view (fixes #1094, #862, #886 )

Clusters

[x] we still need to cluster regardless of the outcome above, so grab a cluster lib. The obvious candidate is: https://github.com/Leaflet/Leaflet.markercluster (there is also https://github.com/SINTEF-9012/PruneCluster but even though it is faster our datasets will be fairly small as we are only dealing with aggregated clusters from the api, so a couple thousand clusters. Also it's clustering isn't as good because it's tune for speed)
[x] Create a custom cluster marker which shows the breakdown of gear styles a pie / donut https://github.com/Leaflet/Leaflet.markercluster#customising-the-clustered-markers (fixes #1610, #985, #483 )
[x] Click on a cluster should zoom into it to split it apart (#498)

Shapes & Labels (eg gara gorge)

[ ] for all of the leaf nodes in the subset tree returned by the api add a label for them. Position this label not in the center of the shape, but the pole of inaccessibility (see #651)
[x] for all nodes in the tree subset returned from the api at any, draw an outline shape. Add click handlers to go to the node page in list view for both the shapes and the labels. Add tooltips for both with the node summary
[x] consider wether we show country / region level shapes. We currently do not for any region. I think we should relax this and not show country outlines, but we should show region but as a fainter line. Then crag and below should be normal.

At this point we are now at 'viewing' feature parity with the current maps minus a host of bugs. We haven't touched the editing side at all, but we can ship this.

STAGE 2: New view features

[ ] later we will add a toggle to show a grade band hot spot for difficulty, and add this to the url following similar facet concept. Note we need to keep the old urls so it may be a special case and not perfectly conform to the new facet graph url structure.
[x] in the map view add the ability to swap between google / bing / osm etc (#653)
[ ] as a crag coordinator allow setting the preferred map provider and type. This should be able to be set at any node

STAGE 3: Editing

[ ] rebuild the editing UI for maps also in leaflet. The big difference is that this page will be dynamic like the maps tab, so you can zoom in and out and edit any boundary or shape as you go. If you pan or zoom to a different area, then it will reload the table under the map showing the unlocated children so that you can select them to add to the map. Clicking any shape will select it, then you can manipulate it. Pretty well exactly like the topo editing.

Now past editing feature parity.

STAGE 4: New Points of interest

[ ] new API which takes geojson for poi and saves it. Need to flesh details but I think each geojson chunk belongs to a node like a topo, but if you extend a track and it now goes outside it's parent then it get auto reparented (like topos). (ie the opposite of the boundary shapes which stretch the parent bbox)
[ ] Add ability to draw points onto a map. Each point has a type eg "carpark" "rap anchor" "cairn" from a set list. A poi can have an optional label such as "North carpark" "South carpark" (#108)
[ ] car park is a special case because we will leverage it for things like driving time. Given a node it needs to be clear what car park it should use. We need to be careful if the car park is away from the crag boundary as so it get reparented up a level. Likewise if there is a crag, which has 5 cliffs, which share 2 car parks, we need each cliff to be able to say which park is primary? I don't like the 'double edit' idea where you have to add the car park poi, and then link it again, this is a pain for simple cliffs. Maybe for the more complex cases we simply show both car parks and let the user decide which for the driving directions. For the automatic distance stuff it could simply choose the nearest car park, but then could also be brittle for cliffs which have a long walk in.

STAGE 5: New tracks and shapes

This would probably be done with stage 4, but we could ship here with just the car park poi for a good win.

[ ] Add ability to draw lines onto a map. Each line has a type eg "4wd track", "path", "track" from a predefined list
[ ] The display of both of the above is purely determined by type. ie 4wd track would be solid white with a black border, path would be dashed white and track would be smaller dotted white.
[ ] some paths, especially the open ones, will not be polylines they will be smooth bezier curves like the topos curves are. Investigate leaflet libraries but this one looks good: https://github.com/elfalem/Leaflet.curve

STAGE 6: Extended shapes, boulders, cliffs, lakes

[ ] some paths with be open, like walking tracks. Some will be closed like a lake or building. This set can be very basic at first as long as we have a couple styles.
[ ] Over time I would like a library of things like "slab" "boulder" "feature" "cliff line" so we can draw full overhead topos onto the map. eg slab would be a closed pale grey with no outline, boulder would be a closed darker gray with an outline. "feature" would be same outline as boulder but open path for drawing a crack or whatever. "cliff line" could be like . We'd probably have a couple different sets for different rock types.

scd commented 7 years ago

This is a great spec and starting point.

brendanheywood commented 7 years ago

Just throwing another idea out there. We've previously talked about using leaflet so we can throw different tile engines at is more easily. It occurs to me that we should probably be able to declare map layers themselves in the db attached to certain nodes rather than in code.

The first example which springs to mind is SixMAPs which is the NSW gov's mapping service which is freely available and they even have a page showing you how to integrate it into a variety of mapping tools including leaflet. Adding it as a layer is a 1 liner and a generic ArchGIS leaflet plugin:

L.esri.tiledMapLayer("http://maps.six.nsw.gov.au/arcgis/rest/services/public/NSW_Imagery/MapServer", {}).addTo(map);

The data itself is released under Creative commons attribution which is awesome, I'm not entirely sure the details for commercial use and sla's etc.

Now this is just NSW, but I imagine there would be a large number of local / state / national government services that we could hook into which are higher quality / more accurate tiles. As we find these we'd want to be able to easily add more on the fly. Even if this is just a few lines of hacky hard coded stuff based on the ancestor nodes that's ok as it's not too much effort to hot fix. But for me the real killer feature is not just for the climber to be able to select these better tiles when viewing, but for the coordinator to be able to select these as the preferred / default tile layer.

I haven't had an exhaustive look, nor checked licensing details, but here are a couple similar services from other states which, like six maps, also have better data than google maps or bing. I think it's safe that there would be a bunch of these around the world.

https://qldglobe.information.qld.gov.au/

http://maps.thelist.tas.gov.au/listmap/app/list/map

http://location.sa.gov.au/viewer/

brendanheywood commented 6 years ago

So I've gone through and made sure we have specs for either apis or algorithms in place for review for the first couple stages to kick off:

the api to sync nodes to a client optionally for offline https://github.com/theCrag/website/issues/3032
algorithm for what boundaries to show, essentially the same as above, all boundaries which intersect the viewport and are greater than some resolution cutoff will show. Only interesting bit here is styling the 'here' boundary differently
algorithm for highlighting selecting current node https://github.com/theCrag/website/issues/1145
algorithm for what labels to show https://github.com/theCrag/website/issues/3036

brendanheywood commented 5 years ago

+1 via https://github.com/theCrag/website/issues/3465

dmucli commented 2 years ago

This ticket seems to have been abandonned. Is it still on the cards to add POIs and tracks to maps?

scd commented 2 years ago

Sure it is still on our TODO list. We are way under resourced so some things take a long time to get to.

For example we have not done Stage 3 but really need to still do it because it is creating some significant issues.

theCrag / website