As mentioned before in feature suggestion #2 in Feedback on use for SOTA I think adding auto-formatting to SOTA reference fields is a good idea. I see Jarrett responded to this after his vacation and mentioned it’s in the works, but I figured I’d mention it again as others are also having issues importing ADI files where the SOTA reference field (including S2S ref field) isn’t formatting correctly: socalsota@groups.io | This looks like a fun challenge.
I was just brainstorming some ways to auto-format this field and figured that one could take the user input, filter all the special characters (spaces, dashes, slashes), count the number of remaining characters to see if it’s 8 characters (which formats to XXX/XX-###) or 7 characters (which formats to XX/XX-###).
One could either do this as a sanity check on-the-fly as the user types the REF (ideally) or when exporting the ADI file. That would help avoid having to manual editing the adi file or going back to the HAMRS app to fix the formatting issue.
This is super helpful actually. I didn’t realize the pattern was that simple. If the two patterns you provided are truly the only formats that SOTA refs come in, it’ll be pretty easy to do. I ran into a problem with formatting POTA parks though, because I allow multiple parks to be entered - is there a similar situation with SOTA? My guess is no, that summits don’t overlap like parks can.
I don’t know of any Summits that overlap like POTA, so I think you’re good there on that front.
As for summit formatting, I realized after posting this that the first 1-3 characters (letters/numbers) can vary (both in the letter/number ordering and length) before the “/”. For example, there’s also “X/XX-###” like “F/AM-281”. The SOTA Summits website has a list of all of them: https://summits.sota.org.uk
I think it’s safe to say that it always ends in “XX-###” where X’s are letters and #'s are numbers. Before the “/”, it can be any combination of 1-3 letters or numbers. So I think filtering out special characters (i.e. - spaces, slashes, dashes, etc) then counting the remains characters to determine if it’s either 6 chars => “?/XX-###”, 7 chars => “??/XX-###”, or 8 chars => “???/XX-###” (where ? is either a number or letter) is the way to go. You can then format the field with the appropriate dash and slash placement. Does seem correct?