Hi Emilia,

For relatively low resolution maps, where sugar moieties cannot be placed unambiguously, in theory (say Agirre  (2017) and Emsley and Crispin (2018)) pyranose placement within the map should be quite highly restrained by ideal geometry for the specific sugar expected from prior knowledge. In practice, however, it’s not entirely clear how to maintain these restraints on pyranose geometry and conformation during manual building in Coot, (....)

I will skip part about Coot as I saw you got some good advice on ccp4bb from Paul but I'll say something re refinement in Phenix..

Meanwhile, in Phenix I don’t do anything specific for the refinement of glycosylation sugars (should I?) other than apply the appropriate restraints for any low resolution EM map; are there specific restraints files I ought to be using within Phenix real space refine jobs for N-linked sugars?

Normally, you don't really need to do anything special. If input geometry is meaningful then everything should be linked correctly and refined fine as well. So.. is this the case?

Then I noticed that loads of existing PDB entries containing N-linked glycans contain similar outliers in pyranose geometry.

Deposited models in PDB are not problems free as was documented by others many times in the past. So what you observe isn't too surprising.

Or is this a tolerable situation where sugar geometries differ from ideal even at low resolution?

Refinement uses restraints on covalent geometry, not constraints. So deviations from idea library values are expected. The higher the resolution, the larger deviations can be tolerable. The lower the resolution, the model idealized geometry is expected.

Is it perhaps a matter of different targets being used for PDB validation by the rcsb versus by Coot?

This is a valid point and may well be the case!

Feel free to send me inputs and outputs and indicate what exactly you find problematic or just worrisome and I will check. Otherwise it's hard to discuss this without looking at specific example.

All the best,
Pavel