Location: Drawing Trails on Maps

[rouletout]

I tried to load a recorded track as access path for a crag. The location feature links to a help text at https://dev.thecrag.com/article/Geolocation#addtrack but even with that I have no clue how to do it. I'm pretty up to speed with map maker and managing tracks and points in MyMaps of Google but how do I get them into theCrag?

[rouletout]

Actually I wanted to do something like that:

[brendanheywood]

Our original strategy for stuff like this was essentially cheating and outsourcing it to google. ie get people to use map maker and add the tracks to google instead of us storing them. This worked really well for a while, but map maker suffered a big spam period and was turned off for a bit, and now I've noticed that a lot of my original tracks have now been removed from google which is a right pain.

We currently have no support for either 'points of interest' (eg car parks see #108) or tracks or shapes other than the crag outline.

There are also plans to be able to have each crag or country set to default to a different map provider depending on which maps are better locally and convert our map code to leaflet, see #365

[rouletout]

Wow, that's a surprise. Check out http://climbingaway.fr/en/rock-climbing-areas/find-20-rock-climbing-areas-close-to-you and e.g. http://climbingaway.fr/en/climbing-areas/hauslberg-leoben - what would it take to implement something like that? These are MUST HAVE features from my side...

[brendanheywood]

we already have something fairly close to the first one, click on maps tab and then 'find me'

https://www.thecrag.com/climbing/world/maps

[rouletout]

Almost, I mean it shows you where you are but that's a weak use case. Also the results are not presented in a very usable way but it is a start. What would it tkae to add a search field and produce results with distance, name, route count etc. as a list?

[brendanheywood]

It's mostly backend as it would be a new api endpoint, the front end would be easy. A strict search by distance isn't trivial but it would be trivial to find a location and then get all crags within say 200km and then rank them by rough direct distance. If you wanted to do it right you really need to sort by distance by road which would probably be a call out to google's api. There may be some cost implication as we might hit their free api limits for the distance matrix call on 2500 a day:

https://developers.google.com/maps/documentation/javascript/distancematrix

Where would you suggest you add a button / link etc to get to this new page?

[nicHoch]

I think we do not need a "distance by road" for a first version. Lets start with the direct distance and lets see how the users react. As a simple workaround we can offer a link to google maps/route with correct start and end point.

[rouletout]

Yes, line of sight is ok - check out the app of 27crags - pretty cool too. I would definitely vote that we have that also in the app.
For the button, can we not just make a search field on top of the map?

[scd]

FYI we can approximate distance fairly efficiently. I have just done an SQL for this in my other job.

In our previous app this was actually one of the features which was implemented really well. In list view each crag had a distance and direction pointer.

[brendanheywood]

Simon just checking you did the proper arc length calc to account for high altitudes? Either way I'm leaning towards the basic filtering being done server side and the distance and direction calculation being done client side so as the gps warms up we can refine and update them without going back to the server again

[scd]

No altitude in formula. Whatever we do will be an approximation. How much difference can altitude make?

There may be another performance complexity with indexes. We have got some good indexes for speeding up searches. However if the underlying query is distance then all the indexes are useless. If we can limit the search to a particular area then the indexes will come into play. I'm guessing that there is some thought required here.

[brendanheywood]

The altitude make an absolutely massive difference away from the equator, in europe you'd end up being wrong by a factor of 2, if the dimension was east - west then the error in tassie which is 42degress south would be cos(42deg) = .74 so you'd be 30% wrong.

See also:

https://en.wikipedia.org/wiki/Haversine_formula

and this:

http://www.perlmonks.org/?node_id=150054

[brendanheywood]

And sorry not altitude, latitude :)

[scd]

Yes well that is simple trigonometry, and that is taken into account.

[brendanheywood]

Simple? So you are using the haversine?

[scd]

The simplest implementation of distance formula I could find

dist_formula = "6371 * SQRT(POW(#{lat}-RADIANS(users.latitude),2) + POW(#{lon}-RADIANS(users.longitude),2)*#{cos_lat})"

It seems fine for small distances, but no good for large distances.

[brendanheywood]

Ah perfect, this is all coming back to me now from way back

[nicHoch]

isn't the migration to mysql 5 a near future milestone anyway? There will be spatial indexes and functions

[scd]

I think we need mysql 5.5. There is no timeline for it. There are a number of significant os migration issues, which I will tackle sometime, but there are some way higher priority stuff to get through first.

If mysql 5.5 does not come with the next debian upgrade then I think I will cry. The last thing I want to do is go outside the debian release schedule for something like mysql.

I think we have to plan to implement something ourselves first.

[scd]

Actually I just remembered what I did in the other system to deal with lack of distance indexes. I made the first level search within a bounded box, which meant I could use the lat and long directly.

Who wants to be the person to take responsibility for this issue. I am happy to do the sql and API, but I will need pestering

[brendanheywood]

There is so much maps related todo's which would be better of implemented as a cohesive block, more or less a ground up rewrite to replace the js with leaflet, allowing per-crag or region alternate tile servers (eg sixmaps, bing, openstreetmap), getting the gear style base clustering done right, the new algorithm for node selection from a bounding box, adding arbitrary line and shape data for tracks, and now this idea of location searching. It's kinda of dead work to implement it now given that most of the js will get ripped out. This would also include redoing the map embeds in list view and the map edit page so they are all the same consistent codebase.

[scd]

Yep I understand.
On Aug 19, 2016 8:47 PM, "Brendan Heywood" notifications@github.com wrote:

There is so much maps related todo's which would be better of implemented
as a cohesive block, more or less a ground up rewrite to replace the js
with leaflet, allowing per-crag or region alternate tile servers (eg
sixmaps, bing, openstreetmap), getting the gear style base clustering done
right, the new algorithm for node selection from a bounding box, adding
arbitrary line and shape data for tracks, and now this idea of location
searching. It's kinda of dead work to implement it now given that most of
the js will get ripped out. This would also include redoing the map embeds
in list view and the map edit page so they are all the same consistent
codebase.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2324 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWxQjTpzk7_Ba7p53z4orguQe8G196fks5qhYm-gaJpZM4JlsJc
.

[rouletout]

I see - from my point of view the map based stuff is really important and spot on on what we should do better than others. Shall we go through it on Tuesday?

On 19 Aug 2016, at 12:49, Simon Dale notifications@github.com wrote:

Yep I understand.
On Aug 19, 2016 8:47 PM, "Brendan Heywood" notifications@github.com wrote:

There is so much maps related todo's which would be better of implemented
as a cohesive block, more or less a ground up rewrite to replace the js
with leaflet, allowing per-crag or region alternate tile servers (eg
sixmaps, bing, openstreetmap), getting the gear style base clustering done
right, the new algorithm for node selection from a bounding box, adding
arbitrary line and shape data for tracks, and now this idea of location
searching. It's kinda of dead work to implement it now given that most of
the js will get ripped out. This would also include redoing the map embeds
in list view and the map edit page so they are all the same consistent
codebase.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2324 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWxQjTpzk7_Ba7p53z4orguQe8G196fks5qhYm-gaJpZM4JlsJc
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #2324 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ASRnSDWwNT74Ydfb1Hf2ggJm0Mq1qqQhks5qhYpMgaJpZM4JlsJc.

---

rouletout608@gmail.com

www.rouletout.ch

[Drazhar]

Is this planned in the near future?

Because right now if you are looking up a crag at theCrag, you don't really know how to get to the crag if the road/path isn't on google maps (which most of the time isn't).

I just thought about using OSM to draw an approach map for some crags like in the most guidebooks, but if in the near future, it is possible to draw the parking space and the path to approach the crag, I don't have to do the work now and draw a map ;)

[brendanheywood]

@Drazhar we can't really commit to hard dates, we can only say that yes this is a priority and we've put it into our release plan.

[Drazhar]

I know that you are doing this stuff in your free time and so you can't give specific dates. Just wanted to know if this is a priority or something for the far future ;)

Right now I tried drawing the approach like this, if the path isn't in Google Map:
https://www.thecrag.com/climbing/switzerland/alpen/sarganserland/area/517769145

Not so happy with this solution, but I think it's better than having nothing if you want to visit the crag for the first time.

[brendanheywood]

Another workaround we've seen a few people do is pull one side of the crag boundary out into a path to the car park. Like this:

https://www.thecrag.com/climbing/canada/calabogie/area/501734961

[birgander2]

Often the osm maps contain much more information about rails than google. It would be great to be able to switch between google and other maps. Currently this is only possible in the location edit, but not in normal view.

Also, it would be cool if your current position is show. Dont know if this is possible and probably more a mobile issue, but many people use the web Version on their phone...

[brendanheywood]

Bump from support email (Henning)

[killakalle]

+1

I have been drawing my own trail in an external tool because there is no support in theCrag atm.
https://www.thecrag.com/photo/3077423673

FYI
On locally used website, I often see Google MyMaps being used (I have no experience creating those maps myself, so far), e.g.
https://elev-arte.com/index.php/escuelas-de-escalada/com-valenciana/valencia/36-escalada-en-chelva/104-escalada-qpico-del-remedioq-en-chelva

[Drazhar]

Hey Killakalle,
yes it would be great to draw lines on TheCrag. My current workaround is:
Since TheCrag supports OpenStreetMaps (OSM), which I also quite like because it's OpenSource, I add all missing approach paths to OSM (see https://www.openstreetmap.org/edit , you do need an account). This ensures that the path to the crag is at least visible on the map of TheCrag.
If the path is not obvious, because there are many intersections or similar, I describe the approach at the approach description and utilize the newish GPS markup of TheCrag:
(description/Icon, lon, lat) As an example see: Saint Pierre

It would be better if this GPS markings could be drawn on the map directly, but maybe they can be transformed from the approach description to the map in the future ;-)

[georg-d]

I think we do not need a "distance by road" for a first version. Lets start with the direct distance and lets see how the users react. As a simple workaround we can offer a link to google maps/route with correct start and end point.

+1 for displaying the rough distance in theCrag plus linking to routing services for details. Please consider to offer also an OpenStreetMap (OSM) based router like GraphHopper or BRouter, because most crags are not next to a major road but small paths - which are much more often missing in Google Maps, Bing Maps, here, tomtom etc. than in OSM, because the companies tend to collect data by driving a car to reduce labour costs, while OSM data is gathered by walking & biking people. Hence, OSM is often more helpful on the last mile, see for example the crag Obere Muggendorfer Wände

• Google Maps sends you straight through the dangerously steep forest because it does only know the wide forestry tracks
• bing leads you to the viewpoint above the crag because it does only know the wide forestry tracks and sticks to them, i.e. moves the end point onto one of these tracks
• here does not even let you enter the target, because it does not accept coordinates as target nor does it know the crag's name (probably because it can't be monetarized like a hotel or theme park). Moreover, it does not know any track or path in the wood.
• GraphHopper (OSM based) simply does the job and displays additional info like directions, distance, time, elevation gain+loss and an elevation profile. EDIT 3/2022: Valhalla is even nicer, because you can adapt many settings like "Maximum Hiking Difficulty".
• BRouter (OSM based) simply does the job and displays additional info like an elevation profile, proportions of different way types and surface qualities. BTW, it can run completely offline on a mobile and can be called via API from other apps; you can try this out e.g. in Locus which does display the map & route & additional info and does output the visual & voice commands.

[georg-d]

I tried to load a recorded track as access path for a crag.

Please let's not re-invent the wheel and/or create dublicate data - which is hard to keep in sync during maintenance! I suggest to re-use Open Street Map (OSM) within theCrag, e.g. so that users can select & link objects like tracks or parkings from OSM in theCrag rather than creating them from scratch again within theCrag's datatbase. For more details, see #108 (comment)

[killakalle]

I've been experimenting with adding approach paths to OSM. It works well, also with the routing of e.g. GraphHopper.

However, I think having the ability to draw paths on sector overview topos would be really nice. Just compare the following image with the OSM map overview from above. It looks a lot nicer and is arguably more helpful if you don't have any OSM navigation tool at hand.

(paths drawn with external tool atm)