Technology. Security. Development. Future.
https://forum.micro-gis.com:443/
Солгасен замена полностью всего коментария - это очень и очень плохо, у меня в них много полезного хранится. Лучше добавлять и менять только несколько ключей в коментарии, например:MaxBel писал(а):Во первых хочу выразить огромную признательность за эту опцию. Она поможет всем картографам, которым необходимо точно отслеживать изменения в картах точно видеть все измененые объекты.
Теперь если можно пару пожеланий:
1. Для новых объектов перед датой дописывать слово Created как вариант, для отредактоированных Edited. ЧТО бы можно было разделить НОВЫЕ и ОТРЕДАКТИРОВАННЫЕ объекты. Это важно.
2. Возможность задать в фильтре групповой таблицы по колонке Комментарий период, за который надо отфильтровать объекты. Т.е. если надо найти все объекты, которые были измененынарисованы за 1 месяц например. Возможно это можно сделать и сейчас, но я не понимаю как.
3. Если кто то уже работает с комментарниями, то затирать чужие наверно не совсем верно.
Пусть первые строки в коментарии будут датой изменения. Именно с них пусть начинается любой коментарий, а со следующей строки пусть будет сохранен старый коментарий если таковой имелся у объекта, например:Fencer_Silver писал(а):Макс - коментарий - это СТРОКА. "Чужой" это комментарий или "свой" - определить нет НИКАКОЙ НИ ЛОГИЧЕСКОЙ НИ МАТЕМАТИЧЕСКОЙ возможности. - остается "как есть".
Смежные полигоны из выделения исключены, как выборкой, так и контекстом. Смежные линии - выделяются все, в том числе заборы и имеющие одну единственную точку пристыковки (на ссылке3 от User_tester она считалась не пересекающейся)Зато DarkDiver теперь может ловить "речки в море". Точки на периметре попадают под выборку, даже если лежат на отрезках между узлами. Дело в том, что это в ФАЙЛЕ - они в столбец. В памяти компбтера (так как их может быть огромное количество) они представлены какDarkDiver писал(а): Пусть первые строки в коментарии будут датой изменения. Именно с них пусть начинается любой коментарий, а со следующей строки пусть будет сохранен старый коментарий если таковой имелся у объекта, например:
; FirstCreated=False
; LastEditDateTime=2012-10-09 20:18:36
; STATUS=Existing
; IUCN=4
; PROTECT=230
; WETLAND=0
; TERR_ECO=TF
; TRANS=1
; DATASOURCE=OOPT_rus_amur
; ACCURACY=Topo_100000-kv
; EDITOR=John Doe
; CODE=179
; PA_POLY=0
; NAME_R=Полтавский
; TYPE_NL=Заказник регионального значения
; PROV_NL=Приморский край
; А ЕЩЕ Я ЗДЕСЬ ПИВО ПИЛ!
Добавлено спустя 39 минут 53 секунды:
И вообще коментарии - это расшареная область для хранения всякой нестандартной инфы, и некоторые программы используют их для хранения своей служебной информации, например тот же mp2mp. И старые коментарии при этом затирать абсолютно не обязательно.
Добавлено спустя 15 минут 41 секунду:
Работу с датой изменения в групповой лучше оформить в виде отдельного поля-столбца.
Т.е. в столбце Comment видим весь коментарий, а в столбце Last Modification - видим только дату и время и соответственно можем работать чисто с датой и временем. То же самое и в окне Object Properties - можно добавить отдельное поле для даты последнего изменения доступное только для чтения.
Такой подход будет и красив и удобен. Затирать же существующие коментарии - однозначно не правильно!
Это я предлагал (ссылка). Мне тоже неудобен текущий вариант...dr.b писал(а):Не нашел, кто предложил в контекст редактора узлов, помимо "Копировать координаты", добавить "Вставить координаты". Однозначно присоединяюсь. Уж очень далеко ходить по пунктам, особенно для POI...
Реализовать в программе поиск в длинной строке некой подстроки начинающейся с заданного ключа ('LastEditDateTime=') задача тривиальная, уверен, ты как профессиональный программист, это и сам понимаешь. Кроме того можно обработать соответствующие ключи и на этапе загрузки файла - в файле то это разные строчки. Короче вариантов решения задачи как всегда множество, тут тебе виднее какой выбратьFencer_Silver писал(а): Дело в том, что это в ФАЙЛЕ - они в столбец. В памяти компбтера (так как их может быть огромное количество) они представлены как
FirstCreated=False/r/nLastEditDateTime=2012-10-09 20:18:36/r/nSTATUS=Existing и т.д. - Т,Е, ОДНОЙ СТРОКОЙ.
Определить - какая часть строки подлежит замене или вывести ее в отдельную колонку...
Ни чего не нужно убирать, функция суперовая просто ее надо немного доработатьFencer_Silver писал(а): P.S. Раз в таком виде коменты не нужеы, то может прибить все? Исключить эту опцию?
Коментарий - это не ключ. У него не ОБЯЗАН стоять 'LastEditDateTime=' и привязывать это к 'LastEditDateTime=' здесь как бы неуместно. А вот о чем писал _Michael_ - вот это пользовательский ключ с полноценным значением (пара ключ - значение). Но если чесно, я уже устал переделывать. Я вчера перелопатил штук 70 модулей (ведь это надо учесть в "ПРИНЯТЬ" - "ВЕРНУТЬ" и т.д.) В общем, не такая это стратегическая задача - все остается "как есть". До лучших времен.Реализовать в программе поиск в длинной строке некой подстроки начинающейся с заданного ключа ('LastEditDateTime=') задача тривиальная, уверен, ты как профессиональный программист, это и сам понимаешь. Кроме того можно обработать соответствующие ключи и на этапе загрузки файла - в файле то это разные строчки. Короче вариантов решения задачи как всегда множество, тут тебе виднее какой выбрать
Большое спасибо!Fencer_Silver писал(а):Хорошо. Завтра будет обновление - поменяем хеш. Все запустится.
Я просто предложил возможный вариант как это можно сделать. Для любой задачи существует множество способов решения. Просто коментарий - это пространство для хранения различных не стандартизованных записей и коль уж программа его использует, то существующие данные разрушаться ни как не должны. Как именно это реализовать - по большому счету все равно. Просто запишите себе в план данную доработку этой функции. Понятно, что у вас есть определенные приоритеты, что делать в первую очередь, а что во вторуюю Просто на мой взгляд это важный момент. Мне эта фишка с записью даты очень понравилась, я бы с удовольствием ею пользовался, но из-за разрушения существующих коментов увы, пока не получится.Fencer_Silver писал(а):Коментарий - это не ключ. У него не ОБЯЗАН стоять 'LastEditDateTime=' и привязывать это к 'LastEditDateTime=' здесь как бы неуместно. А вот о чем писал _Michael_ - вот это пользовательский ключ с полноценным значением (пара ключ - значение). Но если чесно, я уже устал переделывать. Я вчера перелопатил штук 70 модулей (ведь это надо учесть в "ПРИНЯТЬ" - "ВЕРНУТЬ" и т.д.) В общем, не такая это стратегическая задача - все остается "как есть". До лучших времен.Реализовать в программе поиск в длинной строке некой подстроки начинающейся с заданного ключа ('LastEditDateTime=') задача тривиальная, уверен, ты как профессиональный программист, это и сам понимаешь. Кроме того можно обработать соответствующие ключи и на этапе загрузки файла - в файле то это разные строчки. Короче вариантов решения задачи как всегда множество, тут тебе виднее какой выбрать
Пора бы от этого отвыкнуть. Пользовательский ключ - вот пространство для хранения различных не стандартизованных записей. Почему бы не пользоваться? А комментарий - пусть несёт функцию согласно своему названию.DarkDiver писал(а):Просто коментарий - это пространство для хранения различных не стандартизованных записей и коль уж программа его использует, то существующие данные разрушаться ни как не должны. Как именно это реализовать - по большому счету все равно.