Hi James, thanks for all the feedback!
TrigJS wrote: Thu Dec 04, 2025 9:59 am
On the map when displaying the trig points you haven’t logged those logged as “unreachable but visible” are showing on the map as not logged.
Yeah, sorry, the mapping of conditions to colours / icons / buttons is all over the place right now! I'll get it fixed eventually!
TrigJS wrote: Thu Dec 04, 2025 9:59 am
Would a search facility be possible (similar to the old site where you could search by type, use, status, logged or not, distance, etc.)? For example, a search that would output all the primaries trig points that the user hasn’t logged ordered by distance from a defined grid reference.
Yes, but I'm not quite sure where this would sit best. We currently have a low-level
/search screen which is intended for specific stuff, like finding logs mentioning GOMLs, finding everything containing the text 'ben' etc. And we have a high-level
/trigs screen, which is intended for easy slicing and dicing lists of trigpoints. If we expand the /trigs screen to include detailed physical types, historic usage, detailed conditions etc, then where will it end? At what point will power users' requirements overwhelm and bamboozle casual users? Do we need a third screen where power users who have a need to differentiate secondary pillars from primary pillars, or who want a map of all curry stools which have not been found in the last six months, can drill down into the data as they wish?
TrigJS wrote: Thu Dec 04, 2025 9:59 am
Can the export option, e.g. from a search output, be returned? I found this very useful in order to add KML files to Google maps.
Definitely on the ToDo list... but I want the filtering functionality to mature a bit first.
TrigJS wrote: Thu Dec 04, 2025 9:59 am
On the map can more options be included for the filtering of the trig points in addition to pillar, major, minor and intersected? For example, primary, secondary, active, passive, etc.
Filtering on the map screen is actually quite hard, and I've not yet worked out how to get both flexibility and performance. For example, you'll notice that the county filters that I added this morning change the results list in /trigs, but in the /map screen there's no additional filtering, just an extra overlay layer.
So, regardless of the above discussion about filtering, implementing it on the /map screen may be a "no" from a technical competency perspective!
TrigJS wrote: Thu Dec 04, 2025 9:59 am
On the map can the maker for a trig point have the option for a different shape rather than just the TPUK logo? For example, a dot or cross.
Ah, but where will it end? Give the users configurable icons and next thing you know, they'll be demanding a Dark Mode!
TrigJS wrote: Thu Dec 04, 2025 9:59 am
On the page for each trig point the latitude and longitude is WGS84 and not just WGS. Out of curiosity what transformation is used for converting from OSGB36 to WGS84?
tl;dr: no idea!
Regarding the base data... the original spreadsheets I used for populating the pillars came with 10 fig OSGB grid references, but I have no idea of their provenance. The passive station database records were scraped from the OS website (with permission). Both these datasets were converted into ETRS89 using the OS website's bulk OSTN02 conversion tool.
Over time, user-added trigpoints accumulated, whether they were filling holes in the original data loads, new active stations, or Irish trigpoints. Coordinate conversions for these used a basic Helmert transform between the different systems.
On the new website, distances are calculated as great circle distances between WGS84 coordinates, rather than straight-line distances on the OSGB grid. So if you enter an OSGB grid reference in the search box, it'll first convert to WGS84
using a basic Helmert transformation.
At some point, I may grab the latest OSTN15 rubber-sheet transformation and have a clean up of any records where official OSGB documentation exists. But for the majority of the records we have, I genuinely have no idea where the numbers came from. I've merely tried my best not to make them any worse!
TrigJS wrote: Thu Dec 04, 2025 9:59 am
Will trig tools be returning as some of the functionality was useful. For example, percentage of trig points in a county or of a certain type logged was valuable.
I do hope so! I had a chat with Barry before the migration to discuss options. Some of the functionality, such as photo scores, might be added into the core codebase. But as for the data-mining aspects, it all hinges on the answers to the questions you asked above. I'm reluctant to over-complicate the /trigs and /map screens with too many knobs and buttons; but I also recognise the need for the site to have utility and interest beyond planning this weekend's walk! A dedicated area, where UX can take a back seat to functionality, seems a perfect solution!
