Получение информации о столбцах, отвечающих за прямое восхождение, склонение, имя и другие параметры

[Kraysent]

Проблема

Для целей кросс-идентификации и дальнейшего переноса таблицы с 0-ого уровня на 1-й приложению, при загрузке новых данных, необходимо знать, какие столбцы пришедшей таблицы отвечают каким астрофизическим параметрам. Например, при загрузке столбца ra приложению нужно узнать, что этот столбец отвечает за прямое восхождение и его можно использовать для кросс-идентификации.

Причём эти данные могут прийти в разном виде и не обязательно одним столбцом. Например:

1. Информация о прямом восхождении может быть представлена в виде трёх столбцов, ra_h, ra_m, ra_s, в каждом из которых лежат соответственно часы, минуты и секунды.
2. Она может быть представлена одним числом, ra: 10.4356 в часах дуги.
3. Она может быть представлена одним числом, ra: 65.56 в градусах дуги.
4. Она может быть представлена произвольно форматированной строкой, ra: 10h 56m 22s.

Приложение должно (само или при помощи пользователя) уметь различать эти случаи, преобразовывать к гомогенному виду и использовать для кросс-идентификации и для переноса данных на 1-й уровень по итогам кросс-идентификации.

Описание предлагаемого решения

Из найденного в Vizier (SDSS, выборка из DSS, RCSED, FASHI, LAMOST) в основном прямое восхождение и склонение представлены в двух видах - в градусах и в часах (градусах)-минутах-секундах. В первом случае это число с плавующей точкой, во втором - строка формата hh mm ss для прямого восхождения и +dd mm ss для склонения.

Для идентификации величины предлагается использовать UCD (unified common descriptiors) - это специальный стандарт идентификаторов для астрофизических (и не только) величин. Он отвечает на вопрос - какой род имеют представленные данные?. Например, для температуры дескриптор будет иметь вид phys.temperature, для массы - phys.mass, для возраста - time.age. для параллакса - pos.parallax и так далее. Для экваториальных координат используются дескрипторы pos.eq.ra и pos.eq.dec. Полный список дескрипторов ("слов") с описаниями представлен на их сайте: https://www.ivoa.net/documents/UCD1+/20230125/EN-UCDlist-1.5-20230125.pdf.

Таким образом предлагается, чтобы вместе с каждым столбцом пользователь при создании таблицы так же указывал UCD, например в виде

{
  "table_name": "string",
  "columns": [
    {
      "name": "object_id",
      "data_type": "str",
      "ucd": "meta.id"
    },
    {
      "name": "RA",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    },
    {
      "name": "e_RA",
      "data_type": "double",
      "unit": "deg",
      "ucd": "stat.error;pos.eq.ra"
    },
    {
      "name": "Dec",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.dec"
    },
    {
      "name": "V_tau",
      "data_type": "double",
      "unit": "km/s",
      "ucd": "phys.veloc.transverse"
    }
  ],
  "bibcode": "2024NatAs.tmp..120M",
  "datatype": "regular",
  "description": "Some description of the data"
}

Далее полученный UCD можно записывать в метаданные к столбцу и использовать при кросс-идентификации для понимания, какой столбец использовать при кросс-идентификации.

Так же эти же UCD предлагается далее использовать при переводе данных с нулевого уровня на первый - например, каждоый нашей таблице первого уровня присвоить UCD идентификатор(ы), который(е) она описывает и дальше, во время процесса перевода на 1-й уровень, переводить соответствующие столбцы в соответствующие таблицы. Этот вопрос стоит позднее вынести в отдельную дискуссию. Главное - по итогам этого изменения у нас будет необходимая информация.

Для упрощения жизни пользователя можно сделать параметр UCD необязательным и, если он не передан для данного столбца, попытаться выести его из названия. Например, если столбец называется RA или RA_ICRS, то можно автоматически (если пользователь явным образом не указал иное) проставить этому столбцу UCD pos.eq.ra. Но тут есть оговорка - если мы не смогли по названию понять, что это за UCD, а пользователь ничего не указал, есть два варианта действий:

1. Ничего не сохранять и ответить пользователю ошибкой.
2. Молча сохранить столбец без явного указания UCD.

Мне кажется второй подход более правильным - у многих столбцов, загружаемых к нам может не быть проставлен UCD (если загружается старый каталог, например). При необходимости мы сможем руками в базе данных поправить UCD или предоставить в будущем пользоватлю метод для добавления UCD номера в уже существующую таблицу. Альтернатива - пользоватлю придётся руками размечать потенциально UCD идентификаторы для (потенциально) десятков столбцов. При этом скорее всего большую часть столбцов оригинальной таблицы мы всё равно не будем использовать.

Нужно будет так же уметь переводить строково-переданный формат hh mm ss (dd mm ss) в численный. Это делается достаточно тривиально, но, видимо, нужно будет отдельно поддержать условие вида "если формат столбца строковый и его UCD = pos.eq.ra, то попытаться его преобразовать строкой форматирования hh mm ss" при кросс-идентификации и переводе на 1-й уровень.

Компромиссы и ограничения в решении

1. Простым образом не получится обработать таблицу, в которой несколько столбцов с одним и тем же UCD. Например, если в таблице прямое восхожение описывается тремя столбцами - ra_h, ra_m, ra_s, нужно будет во всех трёх указывать одинаковый ucd и каким-то образом комбинировать эти данные. Пока что рассматриваю такой случай как достаточно редкий. Кроме того, при необходимости, перед загрузкой можно скомбинировать эти данные в один столбец и на нулевой уровень загрузить таблицу с одним столбом для прямого восхождения.
2. Первое время мы не сможем корректно обрабатывать сложные строковые столбцы. Если столбец будет иметь формат 10h 56m 22s, то наш парсер с этим не справится. Для большинства каталогов такая ситуация выглядит маловероятной, поэтому предполагаю что на первое время можно так оставить. Если проблема станет очень актуальной, то можно поддержать передачу параметра format, в котором пользователь сможет передать строку форматирования прямого восхождения/склонения/любой другой величины.

Варианты альтернативных решений

Сделать свой урезанный аналог UCD

Вместо того, чтобы поддерживать чужой список идентификаторов, можно придумать свой со список только того, что нужно нам и использовать его.
Плюсы:

• при необходимости сможем добавлять туда какой-то тип данных, которого может не быть в оригинальном списке UCD.
• не будем поддерживать список лишних идентификаторов, большинство из которых мы явно не будем использовать.

Минусы:

• переизобретение велосипеда - в UCD сотни разных идентификаторов, вероятность не найти нужный нам очень мала.

[d-makarov-d]

Поддерживаю решение с ucd, а также то, что он не должен быть обязательным. Столбцы без ucd и unit пропускаем при обработке (так это работает сейчас). Если в метадату для уже обработанной таблицы добавить ucd и unit для какого то столбца, можно будет пересчитать ещё раз, и у нас просто появятся новые данные для этих объектов на 1 уровне.

Несколько уточнений:

По поводу формата данных в столбце (столбцах) с координатами. Astropy справляется с кучей разных способов записать координаты, и в секундах, и в долях градуса, и одной строчкой, и отдельно для ra, dec (причем не в каком то фиксированном формате, понимает фактически все, что в голову взбредет). Так что если Astropy не съел строчку, это что то очень срецифическое, думаю, можно по этому поводу пока не волноваться. Проблема только если например ra разбито на 3 колонки, это можно попытаться обработать на этапе валидации данных, а потом обрабатывать как особый случай

Ещё надо подумать над именами объектов. У нас не обязательно имя объекта одно и в одной колонке. Может быть несколько колонок с именами, может быть одна колонка с именами через запятую. Причем одно из имен "главное", Как вариант, чтобы это обработать, можно придумать свое "расширение" доя UCD. Либо в "корне" json-а (на уровне bibcode) лепить специальную структуру для имен. Что нибудь типо

{
  type: "mulicolumn",
  columns: ["mane1", "name2"],
  primary: 1
} 

К стати, похожее решение можно придумать для координат, а ucd присваивать уже в процессе обработки. Что то типо

{
  frame: "icrs",
  type: "multicol"
  ra_cols: ["ra1", "ra2", "ra3"],
  dec_cols: ["dec1", "dec2", "dec3"],
}
{
  frame: "icrs",
  type: "multicol"
  ra_cols: ["ra"],
  dec_cols: ["dec"],
}
{
  frame: "icrs",
  type: "single_col"
  col: "coord"
}

[Kraysent]

Либо в "корне" json-а (на уровне bibcode) лепить специальную структуру для имен.

Вот тут не очень понятно, где нам хранить метаданные по совокупности столбцов, чтобы потом их использовать при кросс-идентификации и переносе. Если UCD указан для конкретного столбца, куда его положить - понятно - в метаданные конкретного столбца таблицы на нулевом уровне. А вот для совокупности не очень понятно, у нас нет никакого отдельного хранилища для метаданных совокупностей стообцов.

[d-makarov-d]

Насколько помню, у нас есть json-метаданные ко всей таблице, я там даже что то храню

[Kraysent]

Проблемы с оригинальным решением выше:

1. Нет учёта разных эпох для координат - координаты могут быть за 1950 или за 2000, нужно дать пользователю возможность явным образом указать эпохи при желании.
2. Никак не учитывается возможность наличия нескольких столбцов с одним UCD. Причём несколько столбцов могут значить разное:
   • Они могут значить необходимость комбинирования столбцов между собой, например, столбцы ra_h, ra_m, ra_s - их нужно собрать в один и преобразовать к долям градуса.
   • Они могут значить необходимость сделать две записи/два преобразования - например, в каждой таблице у объектов может быть по два имени - одно внутреннее имя в каталоге, другое - общеизвестное имя. Если мы хотим далее делать кросс-идентификацию по имени, может быть необходимо делать её по обоим.
   • UCD может быть недостаточно точным и на самом деле столбцы с одним UCD нужно будет разложить по разным таблицам первого уровня.

Проблемы с решением выноса UCD в отдельную опцию на уровень таблицы

1. Это менее интуитивное для пользователя решение - у людей всегда в первую очередь идёт соответствие колонка -> UCD, а не UCD -> список колонок. Если мы вынесем UCD из уровня описания конкретного столбца, мы спустим на пользователя сложность - наше API будет изначально не интуитивным. Это само по себе плохо (потому что все пользователи будут страдать), но и усложнит нам жизнь дальше при написании веб-клиента, который будет пользоваться этим API.
2. При загрузке таблиц из CDS придётся дописывать дополнительную логику - сейчас в CDS соответствие колонка -> UCD, нам придётся явным образом переделывать её в UCD -> список колонок.

Доработка

Предлагается сделать комбинацию двух решений. Так, в большинстве случаев простых таблиц пользователь будет присылать вот такое:

{
  "table_name": "table_name",
  "columns": [
    {
      "name": "ICRS_RA",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    }
  ],
  "bibcode": "2024NatAs.tmp..120M",
  "datatype": "regular",
}

Если ему хочется загрузить несколько столбцов с одним UCD, но в качестве основного использовать только один, то он может добавить meta.main к основному столбцу:

{
  "table_name": "table_name",
  "columns": [
    {
      "name": "ICRS_RA",
      "data_type": "double",
      "unit": "deg",
      "ucd": "meta.main;pos.eq.ra"
    },
    {
      "name": "OLD_RA",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    }
  ],
  "bibcode": "2024NatAs.tmp..120M",
  "datatype": "regular",
}

В таком случае в качестве столбца прямого восхождения будет использоваться только ICRS_RA (будет по умолчанию предполагаться, что это J2000), а столбец OLD_RA будет проигнорирован. При этом если пользователь попытается загрузить два столбца с одинаковым UCD но без meta.main или с несколькими meta.main на один UCD, то он получит ошибку вида

Unable to determine the main column for UCD pos.eq.ra (Right ascension in equatorial coordinates). To resolve the issue you can:
- specify only one column with pos.eq.ra UCD.
- specify several columns with pos.eq.ra UCD but add meta.main to only one of them.
- specify processing/formatting rules for the columns using `"ucd_params"."pos.eq.ra"` field.

Перечисленного выше должно хватить на подавляющее большинство загружаемых таблиц. Если же таблица нестандартная, то предлагается сделать дополнительное поле ucd_params, в котором можно будет указать форматирование:

{
  "table_name": "table_name",
  "columns": [
    {
      "name": "RA_h",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    },
    {
      "name": "RA_m",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    },
    {
      "name": "RA_m",
      "data_type": "double",
      "unit": "deg",
      "ucd": "pos.eq.ra"
    }
  ],
  "bibcode": "2024NatAs.tmp..120M",
  "datatype": "regular",
  "ucd_params": {
    "pos.eq.ra": {
        "join": " "
    }
  }
}

внутри ucd_params.ucd могут быть следующие параметры (можно добавлять новые, естественно, это просто первое что пришло в голову):

• join: str - слить все столбцы с одинаковым UCD в одну строку с указанным разделителем и использовать результат в качестве главного столбца.
• main_column: str - использовать указанный столбец в качестве главного (эквивалентно присоединению meta.main к столбцу).
• epoch: int - явным образом вписать эпоху, в которую были получены данные. Для начала будет использоваться только для UCD координат, но ничего не запрещает этот же параметр использовать для других, если понадобится.

Таким образом при загрузке таблицы из CDS пользователю нужно будет только указать ucd_params для загружаемых UCD и больше ничего - вся остальная таблица будет загружена в оригинальном виде.

Соответственно при имплементации поле ucd_params будет записано в метаданные таблицы, а конкретные UCD столбцов - в метаданные столбцов.

[Kraysent]

А что ты имеешь ввиду под именами? Поматчить названия колонок в ucd автоматически?

[d-makarov-d]

Не, я про колонки, которые содержат имена объекта. Вот эти все кейсы, где у объекта несколько имен, и они либо в разных колонках, либо в одной через запятую

[Kraysent]

Я думаю для таких случаев можно будет в ucd_params добавить отдельное поле для форматирования

[d-makarov-d]

А какой у имени будет ucd? meta.id?

[Kraysent]

Где как, но обычно meta.id, да
В SDSS, например https://vizier.cds.unistra.fr/viz-bin/VizieR-3?-source=VII/289&-out.max=50&-out.form=HTML%20Table&-out.add=_r&-out.add=_RAJ,_DEJ&-sort=_r&-oc.form=sexa