maps should be able to show where to park your car or other poi parking

[cgome]

We should be able to capture and display the coordinates of where you park your car for each crag/area. Would be good if you could add as either a map-based drop of a pin and/or via entering the lat/long.

Ideally displayed on maps using the international 'P' parking symbol.

When using google maps or whatever to get driving directions to a crag it wold reference the parking location not the centroid of the crag's BB.

• [ ] new process / page / api to enter POI. Each POI has a lat/long, a type (eg parking, toilet, lookout etc, but probably start with just carpark), and an option label and comment.

Eg:

{
  geometry: [123.234,-80.30],
  type: 'poi',
  subType: 'parking',
  title: 'The Springs picnic ground',
  markdown: 'Usually around 20 spots but pretty busy on weekends'
}

• [ ] can have multiple carpark spots for a node.
• [ ] nodes inherit POI similar to tag inheritance

[brendanheywood]

I also think this is a good way of helping determine the subtype f a node. If two cliffs are access from the same car park then they are under a crag level node. But if two different cliffs require different car parks then they are probably different crags. We could add this to our type article to help make people judge this.

[brendanheywood]

Some more use cases to think of:

• Two crags have a long walk in but start at the same car park. If we do conceptually say, yes they are separate crags, should the latlongs be linked to the same POI or just copied? If copied could look weird if they end up on the same map/google earth.
• If a crag has two car parks, we should have one primary for all distance calculations but still treat them the same from a UI point of view.
• If two cliffs are very close and conceptually part of the same crag but there are multiple car parks, should a cliff or other node type also have the car park attribute as an override?
• What about all the other types of POI. I'm thinking BBQ's, toilets, phones, hut, or any arbitrary label. On one hand it would be good to just not bother with this at all. Perhaps find a good source of POI but I doubt one exists at the level of detail we'd want. There is a nice list of predefined POI types standardized by Garmin somewhere

Link to old issue:

https://github.com/brendanheywood/theCrag-DEFUNCT/issues/161

[cgome]

Some more use cases to think of:

• Two crags have a long walk in but start at the same car park. If we do conceptually say, yes they are separate crags, should the latlongs be linked to the same POI or just copied? If copied could look weird if they end up on the same map/google earth.

It would be better to treat as a single POI

-If a crag has two car parks, we should have one primary for all distance calculations but still treat them the same from a UI point of view.

Agree

• If two cliffs are very close and conceptually part of the same crag but there are multiple car parks, should a cliff or other node type also have the car park attribute as an override?

Tricky. As a general rule of thumb one of the thing that defines a crag is that it has its own car park. So if you have two cliffs close by but each has its own car park I'd suggest that they should be crags not cliffs. eg Bushranger Bluff and Declaration Crag at Arapileshttp://www.thecrag.com/area/11740915

• What about all the other types of POI. I'm thinking BBQ's, toilets, phones, hut, or any arbitrary label. On one hand it would be good to just not bother with this at all. Perhaps find a good source of POI but I doubt one exists at the level of detail we'd want. There is a nice list of predefined POI types standardized by Garmin somewhere

Could easily become a distraction for us without adding much value? I'd leave it for now and keep at is a possible future enhancement...

[brendanheywood]

http://freegeographytools.com/2008/garmin-gps-unit-waypoint-icons-table

Reference for gps poi types when exporting to gpx

[brendanheywood]

Idle thinking, should this be db fields you edit, or could we do this with markdown that then gets parsed into those fields behind the scenes?

An example in the wild:

https://www.thecrag.com/climbing/australia/south-west/area/624385557

Drive to 96 Old Kent Rd, Kentlyn NSW (-34.074459, 150.860498). Park on bush side of road next to silver fence. Walk around left end of fence and follow overgrown fireroad downhill for 50m to gully, cross it and continue along vague road with large fence and Bubbas house on the the right for another 50m until better defined fireroad heads down into the bush on the left. Follow this downhill for a few hundred metres, ignoring minor side tracks, until a large dirtbike jump appears on the left. Walk past this and down to major intersection with yellow street sign. Walk right along fireroad for 20m and look for rock cairns and blue tape markers that show the start of the climbers track (-34.077626, 150.858130). Follow cairns and blue tape along flat ground then steeply down rocky hillside to crag (-34.077876, 150.855652). It is right above the large swimming hole.

Could this be modified in some simple way to make a bunch of markers on the map?

I see some benefit to always having the location in numbers, and embedded in the text makes more sense. The biggest downside to this is what I'd also like to be able to draw lines and shapes on the maps, not just points, and this would be completely unwieldy in markdown and painful to edit.

[brendanheywood]

Another +1 from facebook:

https://www.facebook.com/thecragcom/posts/10153533269322604

[quaestor]

+1 from me. It's often tedious to describe where to park in the crag description.

[dnnr]

Came to GitHub today, ready to post this as a new issue, fortunately found this ticket. Strong +1 from me!

[brendanheywood]

Another example in the wild:

http://www.thecrag.com/climbing/australia/grampians/the-lost-world

[dmucli]

+1

Adding POI to the maps would be super useful. Some random ideas in order of importance:

• car park
• track
• descent / rap station
• toilets / water
• shelter
• lookout

[brendanheywood]

+1 from support email

[killakalle]

+1 in combination with https://github.com/theCrag/website/issues/2324

[georg-d]

Please let's not re-invent the wheel and/or create dublicate data - which is hard to keep in sync in the long term maintenance! I suggest to re-use Open Street Map (OSM) within theCrag: In contrast to before mentioned Google Maps, in OSM, you can not only get the rendered tiles (=pictures) but you can get and edit the underlaying data. There is a mature data model and a massive existing dataset, maintained by a big amount of people (=POIs are more likely to be complete & up-to-date when theCrag is partnering with OSM than having theCrag's user-base alone). The data is used e.g. by many map apps on mobiles (=POIs entered in OSM can be directly seen/searched/navigated/edited in the apps insteadt of needing a cumbersome GPX export/import). There are already many editors, be it in the browser (e.g. iD or Potlach) or as Java application for laptops/desktops (JOSM) or as mobile's app (Vespucci), and there are many rendering, quality assurance and other softwares (=theCrag's team can focus their dev resources onto climbing relevant features in theCrag instead of re-creating existing & mature features).

I imagine to be able to select & link objects like parking/toilet/shelter/path/track/... from OSM in theCrag rather than creating them from scratch again within theCrag's datatbase. These POIs / objects could be highlighed & clickable and may be enriched in theCrag by additional information focused on climbers (textual description, pictures, weather forcast, routing, ...), see e.g. xctrails.org for an idea what I mean. If a browser based OSM editor like iD could be used directly from within theCrag, climbers could add/enrich/update objects in OSM which would be quite convenient and helpful for both projects - but a simple link "edit in OSM" would also be fine IMHO.

[killakalle]

Just an example that I have come across that I think is nicely done: AllClimb app

The map shows the location of crags, parking and trails. It can also show your own location based on GPS

[georg-d]

If POIs were a database entity on it's own (i.e. not a private child of a crag), multiple crags could point/link to the very same POI (so 1 POI exists for all crags, not one dublicate per crag) - allowing to follow links in both directions which opens up quite interesting possibilities, especially listing all crags having an association to a given POI. To see the idea working, click a POI in hikr.org which shows a pop up with all reports & photos etc linking to that POI. One example use case in theCrag would be to click a public transport stop position POI of a "good" bus/train/... line (i.e. high timetable frequency, quick to reach from my start position,...), producing a list of all crags using that POI - allowing to easily find the crags that are well reachable by public transport.