Населенный пункт - всегда ли?
-
Это сообщение удалено! -
Спасибо!
Я спрашивала, потому что всегда будут начинающие и очень-очень начинающие операторы, и сформулировать нужно для их понимания, а затем занести в методичку.
Если на них еще обрушить и административное деление, они просто сбегут. Именно так они могут воспринимать в принципе правильную формулировку Антона: "в Анкете ПЗ волость и уезд указываем как правильно по административному делению на 40-е года, а в примечаниях ПЗ как записал писарь".
Поэтому, возможно, следует сформулировать ближе к формулировке Александра:
"если оператор знает или установил правильное название волости и уезда, соответствующее административному делению Латвии 40-х годов, то в карточке ПЗ указывает правильное название, а в примечаниях - как было записано в донесении;
если не знает или не может установить, то в карточке ПЗ указывает то название уезда и волости, которое есть в донесении".
А старшие товарищи проверяют и делают запись в карточке: "Проверено. Мин нет. Старшина Сидоренко" :)))) т.е. должна быть пометка, кто проверил. Может @dima предложит элегантное решение?
Что думаете @венский , @Виктор-Тхор , @Ржавин, @Александр? Предлагайте свои варианты формулировки, пожалуйста. -
Участник @Наталия-Леле написал в Населенный пункт - всегда ли?:
"в Анкете ПЗ волость и уезд указываем как правильно по административному делению на 40-е года, а в примечаниях ПЗ как записал писарь".
Это, в принципе, не такая тривиальная задача как может показаться на первый взгляд: Например сразу возникает вопрос - А как мы хотим искать эти ПЗ в списке?
Потому что сейчас это название со всеми населенными пунктами "сливается" в одну строчку и используется для показа этого первичного захоронения в списке, а также для поиска этого первичного захоронения.
А как тогда быть в том случае, если у нас будет больше одного варианта написания этого первичного захоронения?
(Это только один из вопросов который предстоит технически решить в этом случае) -
Надо сделать ещё одно поле для записи "Как указано в первичных документах" и пускай оно сливается в конце записи в скобках.
По выше преведённому примеру:
300 м. севернее хутора Дирбас, Джукстес волость, Елгавский уезд (300 м. севернее хутора Дирбас, Пиенавас волость, Тукумский уезд )
-
Никакого классификатора для нового поля не нужно, туда можно просто копировать текст из ОБД.
-
Участник @Ржавин написал в Населенный пункт - всегда ли?:
@Виктор-Тхор В принципе, да. Но это если у нас только Латвия. А у меня уже трое по Валмиере, которые в Литве, Эстонии и Польше. Классификатор "административное деление" тогда огого какой запутанный станет.
Для наших целей в классификаторе достаточно указать - "похоронен за пределами Латвии"
-
@Виктор-Тхор А где именно за пределами Латвии разве не интересно? Ведь платформа, насколько я понимаю, стремится к экспансии в другие регионы - РФ, Эстония и т.д.
-
@Виктор-Тхор
300 м. севернее хутора Дирбас, Джукстес волость, Елгавский уезд (300 м. севернее хутора Дирбас, Пиенавас волость, Тукумский уезд ) конечно слишком длинно.
Чтобы не возникало таких сложностей, может, просто в самом деле в общем списке ПЗ нужно видеть и колонку дополнительной информации с возможностью поиска. В ней будут отражаться в том числе все неправильные варианты написания топонимов.
Идея та же - в основном списке солдат должна быть показана правильная информация о ПЗ.
А последовательность работы м.б. такой (особенно это важно определить для непродвинутых операторов):
Встречаясь с новым для него ПЗ в донесении, оператор сначала ищет его написание в основном списке ПЗ, если нет, то в колонке дополнительной информации того же списка.
Если находит соответствующее ПЗ - прикрепляет,
Если не находит, то оформляет сам и прикрепляет :
А) продвинутый оператор оформляет правильное написание топонимов в основных строках, все неправильные написания в дополнительной информации.
Б) непродвинутый оператор оформляет так как видит в документе, дополнительно найденные в документах искаженные написания соответствующих топонимов отражает в дополнительной информации. И обращается за консультацией к продвинутому оператору.Результат - чистый красивый общий список солдат с правильной проверенной информацией.
@Ржавин @венский @dima @Александр -
@Наталия-Леле Любой может научиться искать места ПЗ. Карты данны, список волостей и уездов тоже.
-
Антон, Вы абсолютно правы, научить и научиться можно всему. Но со временем, поэтапно, переходя от простого к более сложному.
Когда человек только начинает, ему даже очень простые действия кажутся очень сложными. Поэтому, если навалить на такого неопытного оператора все сразу, он запаникует и может вообще сбежать.
-
Участник @Ржавин написал в Населенный пункт - всегда ли?:
@Виктор-Тхор А где именно за пределами Латвии разве не интересно? Ведь платформа, насколько я понимаю, стремится к экспансии в другие регионы - РФ, Эстония и т.д.
Там в любом случае будет другое А-Т деление: Страна-Республика-Область-Район-Сельсовет
-
@Виктор-Тхор Вот именно. То есть надо уже сейчас заранее продумать все эти заморочки с разными странами.
-
Здравствуйте! После конференции в Москве где была представлена платформа это неизбежно.Идея слишком обьективна чтобы её не использовать.Мой регион Белгородская область РФ.Район южного фаса дуги.Мемориалы на сотни и тысячи человек.Почти нетронутые обработкой. Пока постараюсь разобраться и использовать то что есть ,но уже видно что необходима унификация платформы.
-
Мне кажется, чтобы потом легче было искать, в случае нахождения привязки нашего бойца к мемориалу зв пределами Латвии можно регистрировать фантомный мемориал "Название+Страна".
Это временная мера конечно же. Но без нее в настоящее время никак.
@dima -
Пока попытаюсь использовать платформу для ускорения обработки.В отчетах прийдётся делать коррекцию.
-
Ув. Коллеги!
Разумеется, платформа разрабатывалась и разрабатывается с учетом того что ей будут пользоваться в разных странах и регионах.
Сейчас пользователи из Латвии и из России видят совершенно разную картину на Платформе.
Например, у вас Александр @Гангут я вижу только 3 первичных захоронения (это нормально, Вы только начали работать).
А у ваших латвийских коллег их введены уже сотни.
То есть Платформа уже делит содержимое по пользователю который, в свою очередь, привязан к конкретной стране.
В принципе Вы правы @Гангут , для российских пользователей, скорее всего, надо ввести области, районы и, возможно, какое-то другое (дополнительное) географическое деление.
По идее, чтобы не делать 100 интерфейсов для 100 разных стран, мы можем, просто, в какой-то стране не использовать географическое деление предназначенное для другой страны.
То есть, например, латвийские пользователи могут оставлять поле "область" не заполненным. -
@dima Чтобы не плодить тем напишу здесь.В РФ при увековечивании приходится работать с военкоматами .Там есть необходимость составлять списки по форме 19БП .Также полезно было бы иметь возможность в "Сверка в XLS" колонку со ссылкой из ОБД на воина.В военкоматах пока запрещен интернет и сотрудники обрабатывают материал дома.
-
@Гангут ну, разумеется, если такая ссылка вообще есть (ID с ОБД - заполнен). Т.к. технически, её может и не быть.
Кстати, что это за форма 19БП?
Может, расскажите про неё в отдельной теме?@Наталия-Леле , дополнительная колонка никому мешать не будет?
-
@dima, больше того, Виктор все время говорит о том, что в Excelе должно быть как можно больше колонок.
Я не против, я только за :). Тем более, что у КБК допуска на Платформу тоже нет и той информации, которая в настоящее время есть в файле сверки, им тоже недостаточно.
-
По форме 19 выяснил что это внутренняя форма военкомата.И в платформе не нужна. Однако её составление военкоматом влияет на ход увековечивания. Поэтому необходимо запрашивать её составление в РФ.
Сылки с ОБД присутствуют во вкладке -Документы.Их отражение в Excelе необходимо для первичной обработки данных в РВК. Вопрос только чтобы первой(или хотя бы единственной ,что бы не перегружать военкоматовцев) отражалась основная ссылка из карты воина.