reference channel usually gets ident=0, then all other channels start from 1

>>> import mne
>>> info = mne.io.read_info(mne.datasets.sample.data_path() + '/MEG/sample/sample_audvis_raw.fif')
>>> info['dig'][85]
<DigPoint |     EEG #0 : (2.4, 111.0, -35.0) mm    : head frame>
>>> info['dig'][86]
<DigPoint |     EEG #1 : (-37.4, 105.7, 73.3) mm   : head frame>
>>> info['chs'][315]['ch_name']
'EEG 001'
>>> np.round(info['chs'][315]['loc'][:6] * 1000, 1)
array([-37.4, 105.7,  73.3,   2.4, 111. , -35. ])

Hm, so that would mean losing the EGI channel numbering -- is that preferable? I'm not sure, but couldn't there be a situation where you'd be looking at the locations and wanted to know which channel that was? Or would you always be looking at the info['chs'] when this is relevant?

I.e., seeing <DigPoint | EEG #0 : (2.4, 111.0, -35.0) mm : head frame> might be misleading if it does not correspond to the channel named E0...

Yes the idea is that we take each format and make it conform to the info spec as much as possible. If for some reason we need the original ordering then we should store it in a public attribute or something.

One more point is that the EEG dig entries with idents 1...N should be in the same order as the EEG channels in the data/Raw instance. But maybe you have it this way already.

Yes it's an unfortunate coincidence that they start their numbering at zero and this collides with our dig repr which always says EEG #N starting from zero, but I think we should live with it and not deviate from our standard behavior here

One more point is that the EEG dig entries with idents 1...N should be in the same order as the EEG channels in the data/Raw instance. But maybe you have it this way already.

This is the case with the exception that the reference seems to be always the last EEG channel in the EGI format (as well as the mne objects created by the current importer).

So did I understand correctly that we want to move the reference and call it #0 in dig but leave it last in the data/chs?

Oh it actually shows up as a channel in the data, too (just with necessarily zero value)? Then I guess in that case it's okay to leave it as is. The alternative would be to duplicate the point but I don't think that's a good solution. We can reconfigure later if need be

Yes it's in the data with all 0s.

In [2]: raw = mne.io.read_raw('test_egi.mff')

In [5]: raw.ch_names.index('E129')
Out[5]: 128

In [10]: numpy.all(raw._data[128] == 0)
Out[10]: True