SQL и XPath против РосРеестра

Отличный вывод! Теперь вам не надо ждать, когда вас спасут.
А вот этим кадастровым инженерам надо, ибо большинство из них не владеет sql, у них нет лицензий на MsSql и доп. инструменты (которые еще нужно изучать)
С таким же успехом они могут написать/подправить парсер xml на своем любимом языка программирования.

Я взял бесплатные Express версии и решил задачу — обработка данных. Эти древние форматы просто не нужны — вся работа прекрасно делается в СУБД на голом SQL'е

Ни и с Python'ом вообще сказка будет

Только Ваши запросы работать не всегда корректно будут, т.к. нужно учитывать порядок обхода контура, учитывать «бублики», многоконтурные участки. Еще есть понятие подучастков и вашим запросом Вы получите координаты по ним и все будет в одной куче, отстроить ничего не получится. также Росреестр выдает координаты как точками, так и линиями и все это нужно учитывать. Задача не такая простая, как может показаться на первый взгляд. Но в целом подход правильный, просто в реальной жизни его реализация будет более сложная.

Хотелось бы добавить, что работу с xml в sql server можно несколько упростить двумя вещами:

• использовать * вместо неймспейсов:

  
  

  SELECT @Xdoc.value('/*:*[1]/@CadastralNumber', 'nvarchar(max)') as CadastralNumber, 
  [dbo].[SpatialElementToLineString](Parcel.query('.')) as geom 
  FROM @Xdoc.nodes('//*:SpatialElement') col(Parcel);

  
  

• использовать латеральный джоин ( в sql server — это cross apply / outer apply)

  
  

  select t.id, X.tag1, X.tag2 
  from table t cross apply ( select t.xml.value('//*:tag1') tag1, 
                                    t.xml.value('//*:tag2') tag2 ) X