Removing old/bad info from summit detail pages

Is there a procedure to have bad or outdated information removed from a summit’s page? For example, W4G/HC-043 says that the summit is a drive-up and that the Riverside Day Use area, which is the best trailhead, is closed.

However, the drive-up route was through an under-construction subdivision which is now gated. The Riverside Day Use area is open, and has been since at least Nov 2019, the last time I visited.

1 Like

Usual procedure is to provide an updated entry. I am in the process of doing a dead link cull, but this won’t fit into that.

:+1: :+1:

1 Like

Maybe you could add a button to the summit pages that allowed a user to report a required update? If it’s right there in front of a user it’s more likely to get used than if they have to go search the contact/FAQ page for the right person/procedure.

Surely the difficulty is who will check all these updates to ensure they are accurate? A chronological progression will end up with old information which may be inaccurate but if it’s dated and newer information is available the user can make their own choices.


The problem is that some people don’t take the time to read everything. They will see something and then think “Oh, well I’m gonna go ahead and swing by this drive up on the way home” without reading further.

There is the question of who would vet the new information, but no one vets the old information. Maybe something to flag a comment as “Possibly outdated” rather than removing it.

I added comments to the summit in question with updated info. Hopefully people will take notice.

My point of view on that:

Wiki approach is the way to go. Add version control to articles and links and let the SOTA community fix the errors. Including deleting false information, fixing links and so on.

73 Joe


Yes, that is ultimately the aim. Time, etc. :slight_smile:


The site could be flagged to indicate that a potential, but unverified problem exists. This could be done quickly, long before it is officially verified. It would give notice that, before one sets out on a hike, they should look into this a bit further. It would seem reasonable that anyone could set the flag to warn that there may be a problem and one should check further.


I like the historic nature of the summit information postings by activators. Things change over time and the summit postings reflect the changes as well as the skill of the activators in describing accessibility. I also look at the Peakbagger web pages and Gaia maps. If an activator feels that prior postings are no longer accurate then posting update personally experienced information is helpful. I do not want a wiki style editor to “correct” prior entries.

The dead link cull is complete. About 1350 links were marked invalid, due to returning a 4xx or 5xx HTTP error code, and the API updated to not return these invalid URLs. Should the sites come back, it will be possible to readd in the links (but most of them are dead, dead).

There’s a reasonable amount of 3xx codes returned, but I did not cull these even if I suspect some of them redirect to index pages instead of returning 404.

1 Like

Yesterday I’ve edit some info on the summit detail pages. All worked fine.

But when I today wanted to edit my link on CT/AL-007, the link was gone. When I tried to make a new link, it didn’t add a new link. Strange. Both the links on CT/AL-005 and CT/AL-007 are now gone after I did an edit.

OK, this is now fixed. For the dead link removal, I set a flag on the link to be valid/not valid. I have a default constraint on this column to set to Valid. The API however, rather than trying to use the constraint, silently set the result to Not Valid when inserting or editing links and articles. It’s explicitly set to Valid when adding or editing a link now.

Thanks, I just added a link to my CT/AL-004 / 005/ 007 SOTA youtube.

73, Tonnie - PA9CW