Yes, sorry, I stopped examining your posted config after I saw the parseFloat issue. You have a second hidden issue here: the difference between getting an item via the repeater’s itemsInGroup source and via the items object.
When you use the itemsInGroup or itemsWithTags source options, the repeater makes a call to the OH API, gets the return JSON object, and uses that object as the source array. That JSON onbject, however, is just a static snapshot of the item at that time (it’s just text). If you go to the API explorer in the Dev Tools and run an /items endpoint test call you’ll see an example of all the output that is in the repeater array. This doesn’t include numericState, just state.
These two facts are why the items object exists. When you access information about an item using items.ITEM_NAME_HERE or items[ITEM_NAME_VARIABLE] two things happen: 1) you get a very reduced, but improved object in response (this does include numericState), 2) that item is added to a list of items to be tracked by the UI so that the value can be updated automatically if it changes.
So, for your map expression, you don’t want a.state, that’s a static value that won’t change (and you can’t get numericState from a). What you want to use instead is, for example items[a.name].numericState. This will be the number-converted reactive value for the state of that item.
There’s a further shortcut about getting the numericState from the items object: #ITEM_NAME is the same as items[ITEM_NAME].numericState. So, you your map value can just be:
map: loop.station_source.sort((a,b)=>#(a.name)-#(b.name))[loop.station_idx]