| Обсуждение |
| |  Предложения для ол [ ViFIZEG ]Понедельник, 25 июня 2007, 09:12
| А нельзя ли сделать передвижения точек с помощь стрелок а не мышки с указанием шага сдвига. допустим alt+ ^ cдвиг точки вверх на 1 метр(или 1 см). а то бывает необходимо видить картину в целом... |
|
| | [ ObjectLand Support ] Понедельник, 25 июня 2007, 10:59
|
| | [ ViFIZEG ] Понедельник, 25 июня 2007, 11:05
| Во всех просто щаз сижу необходимо сдвинуть линию гдето более менее точно мышкой особо не здалаешь приходится делать лишние операции... ) |
|
| | [ ObjectLand Support ] Понедельник, 25 июня 2007, 12:14
| Записываем это в свой список предложений |
|
| | [ ViFIZEG ] Пятница, 6 июля 2007, 10:33
| а не планируется ли разработка ол для линукса... |
|
| | [ Максим Юрьевич Трухачёв ] Пятница, 6 июля 2007, 18:11
а не планируется ли разработка ол для линукса...
- сплюньте и перекреститесь! Линукс хорош в качестве ящика в серверной, который настраивают раз в жизни и не трогают годами. И потом, какой COM-интерфейс под Линуксом ? По моему мнению, ОЛ-у не хватает встроенного языка программирования, в идеале - VBA, хотя пусть будет любой язык, хоть Java. |
|
| | [ Максим Юрьевич Трухачёв ] Суббота, 7 июля 2007, 21:51
В редакторе макетов хорошо бы сделать:
1) инструмент "измерительная линейка", как в окне просмотра темы.
2) возможность задавать полигональный "контур обрезки" сложной формы для таких элементов, как темы и растры. |
|
| | [ ViFIZEG ] Понедельник, 9 июля 2007, 14:26
| Максим Юрьевич производительность под линами повышается на 10-13 % при работе с базами нежели под виндами.. тестировал все под вайном в сэме... если будет встроенный язык хотябы наподобие явы или как мапбейсик необходимость в ком интерфейсах отпадет вообще как таковая..что будет иметь еще большую ценность использования данной гис.. |
|
| | Предложение по графическому движку [ Максим Юрьевич Трухачёв ] Пятница, 31 августа 2007, 00:43
| Предложение по графическому движку. Если сильно отодвинуть (zoom out) изображение в окне темы, то объекты "исчезают" (мы видим белое поле, хотя окно темы покрывает некоторое непустое множество объектов). Это очень неудобно, когда приходится искать скопление объектов, не зная их расположения. К тому же некоторые "случайные" объекты могут далеко отстоять от основной массы объектов, их бывает нужно найти и удалить. Вот в Автокаде наоборот: при любом удалении группа объектов продолжает отображаться, хотя бы в виде единственного пиксела. Это очень удобно пользователю при навигации. Понимаю, что такое положение вещей не случайно, и хотелось бы узнать, насколько реально его поменять "в автокадовскую сторону" ? |
|
| | [ ObjectLand Development Team ] Понедельник, 3 сентября 2007, 14:06
>Предложение по графическому движку
Это поведение не имеет отношения к "графическому движку".
Для быстрого поиска объектов, необходимых для отображения, ObjectLand ведет пространственный индекс. При отображении при заданном масштабе ObjectLand НЕ ИЗВЛЕКАЕТ (заметьте, это выполняется не на этапе прорисовки) те объекты, которые будут отображаться размером в пикселах ниже заданного нами порога видимости. Это позволяет не извлекать и не анализировать очень мелкие объекты для текущего масштаба, что существенно повышает скорость отрисовки при общих планах. Если сделать не так, то в общем случае эти объекты должны извлекаться и отображаться (в нескольких пикселах еще и с учетом заданного стиля).
Автокадовское поведение имеет единственное преимущество - видны точки вместо мелких объектов, т.е. это как бы визуальный поиск.
В ObjectLand поиск мелких объектов можно делать используя прямоугольную или полигональную селекцию.
Ваше предложение мы запишем, возможно со временем (не сейчас) сделаем некий вспомогательный (черновой) режим просмотра с учетом всех объектов, попавших в тему. У нас есть от других пользователей ряд предложений, подходящих для введения чернового режима просмотра. |
|
| | [ Максим ] Воскресенье, 9 сентября 2007, 20:00
| Вы пишете: "поиск мелких объектов можно делать используя прямоугольную или полигональную селекцию". Но, сделав селекцию, можно лишь узнать количество объектов, попавших в селекцию - селектированные мелкие объекты не подсвечиваются. Пусть будет режим "просмотра центроидов", когда в окне отображается единственным пикселом только центроид каждого объекта, независимо от его размеров и стиля. Тогда пользователь увидит примерно то, что видит автокадовец (конечно, не совсем - ведь крупные объекты тоже отобразятся пикселом). На мой взгляд, это компромиссное решение, пригодное для некоторых оценок и поиска. |
|
| | [ ObjectLand Development Team ] Понедельник, 10 сентября 2007, 11:41
| В черновом режиме, о котором я писал выше и который мы запишем в TODO, крупные объекты должны показываться как есть, а мелкие (размер ниже определенного порога) в виде точки без попытки отрисовать объект заданным стилем. |
|
| | [ ViFIZEG ] Вторник, 11 сентября 2007, 08:37
| А нельзя ли сделать выравнивание для текстовых полей в макетах.. |
|
| | [ ObjectLand Support ] Вторник, 11 сентября 2007, 11:22
>А нельзя ли сделать выравнивание для текстовых полей в макетах..
Что Вы понимаете в данном случае под выравниванием? Дело в том, что текст в макете не имеет ширины, поэтому для не ясно как выравнивать. |
|
| | [ ViFIZEG ] Вторник, 11 сентября 2007, 14:45
| задать канкретную ширину/высоту визуально т.е. растянуть допустим как размещение текстового элемента на форме с выравниванием влево/право/по середине |
|
| | [ ViFIZEG ] Вторник, 11 сентября 2007, 14:46
| текста в самом текстовом поле |
|
| | [ ObjectLand Development Team ] Вторник, 11 сентября 2007, 16:35
На настоящий момент такие изменения сделать не можем. Чтобы обеспечить такую функциональность нужно изменить формат сохранения макета в ГБД (а также конечно и модель представления текстов в макете).
Еще раз объясню нашу позицию в отношении функциональности макетов:
мы обеспечиваем базовые решения по подготовке данных ГБД к печати, т.е. те решения, которые позволяют среднему пользователю быстро подготовить данные к печати. Какие бы мы локальные проблемы не решали, мы не угонимся за специализированными пакетами презентационной графики (Corel, Adobe CS и т.п.). Поэтому для высококачественных работ по печати не обойтись без экспорта графики в эти пакеты. Лучше это сделать путем вывода в EMF или Postscipt, чтобы пакет при импорте восстановил эту графику в векторном(объектном) виде. |
|
| | Медлительность COM [ Максим ] Четверг, 20 сентября 2007, 04:29
| Не планируется ли открыть для использования сторонними разработчиками API ObjectLand, как это сделано, например, в ГИС "Панорама" ? Это позволило в десятки-сотни раз ускорить работу приложений, выполняющих обработку геометрий и записей поштучно. Например, я написал приложение, реализующее концепцию "аннотаций ArcGIS" в ObjectLand. С приложением "Подписи" я не знаком, а принцип работы моего приложения прост: некий текстовый тип геометрии ссылается на ту же таблицу, что и некий нетекстовый. По номеру "общей" записи они и связаны, геометрия (например, линейная) и её подпись (текстовая геометрия). Возможностей открывается масса, к тому же это универсальный подход, в отличие от приложения "Подписи", "заточенного" под требования Росземкадастра. Всё у меня работает корректно, но неприемлемо медленно - сутками. И лишь потому, что реализовано в виде COM-клиента, а иначе в OL нельзя. Есть и другие идеи использования факта привязки нескольких геометрий из разных типов к одной и той же записи, но если они будут так же медлительны, то какой прок их воплощать ? Медлительность COM-клиентов является мощным тормозом на пути насыщения OL сервисными функциями и утилитами, нужными не всем пользователям, а лишь их части, и потому никогда не включаемыми в планы развития "базовой" ГИС. Тем не менее, всякая платформа сильна именно разработками. Что об этом думают авторы OL ? |
|
| | [ ObjectLand Development Team ] Четверг, 20 сентября 2007, 13:14
К сожалению, мы не можем предоставить иные возможности сторонним разработчикам, кроме COM. Конечно программное ядро на нашем внутреннем уровне хорошо специфицировано и мы бы с удовольствием давали бы такую возможность другим разработчикам, но без использования инструментария разработки использовать его нельзя, распространять средства разработки вместе с продуктом запрещено лицензионным соглашением инструментария. Цена инструментария запредельная - 5 тыс.долларов на одного разработчика. Поэтому единственный способ - использование COM.
***
Советуем также использовать приложение "Подписи". Создание его не имеет никакого отношения к Росземкадастру. Это универсальное приложение, которое мы со временем "опустим" на уровень системы. Во время его работы не создаются объекты карт, только поверх объектов отображаются подписи (с кучей настроек, автообновлением и т.п.).
*** |
|
| | [ ViFIZEG ] Пятница, 21 сентября 2007, 08:49
| Насколько я панимаю вы в приложениях используете SmallTalk... по крайней мере пахоже на это,... так вот суть не в этом никто не просит вылаживать/поставлять инструментарий вместе с OL достаточно просто описать на чем и механизм работы.. а дальше выбор предоставить конечному пользователю, либо разрабатывать используя инструментарий либо использовать сом интерфейсы... |
|
| | [ ObjectLand Development Team ] Пятница, 21 сентября 2007, 12:15
| Такого выбора нет, как объектная библиотека ObjectLand доступен ТОЛЬКО из Visual Smalltalk. Цену на него я написал выше. |
|
| | [ ViFIZEG ] Пятница, 21 сентября 2007, 13:58
| =) лан будем считать что на данный момент данная часть является закрытой... и всетаки хотелось чтоб бы в будущем был рассмотрен такой вапрос т.к. несмотря на "преимущество" использования сом-а хотелось бы использовать ол в других ос (100% работает).. |
|
| | А почему не VisualWorks [ Денис ] Понедельник, 24 сентября 2007, 11:44
| Если не секрет, а почему до сих пор не портировано в более современные среды Smalltalk? Например, в родственный (если не ошибаюсь --- ведь под "Visual Smalltalk" имеется ввиду ныне Cincom-овский VSE?) VisualWorks? И самим программировать, наверняка, будет приятнее (не знаю, как у вас дела с юнит-тестами, рефакторингами и проч., а у нас нормально:)), и аудитория значительно расширится... и кроме COM можно будет другие способы общения с несмолтоковским миром попробовать (SOAP тот же, к примеру)... и web-интерфейс организовать приличный (seaside)... |
|
| | [ ObjectLand Development Team ] Понедельник, 24 сентября 2007, 13:01
Просто наша разработка начиналась еще со Smallalk/V под DOS. К сожалению, VisualWorks и VSE сводные братья, не кровные:).
В до .NET-овские времена конечно мы рассматривали VisualWorks как первого кандидата для портирования, учитывая неважное состояние Digitalk и затем ParkPlace. При всей развитости VisualWorks нас останавливали прежде всего проблемы пользовательского натив-интерфейса приложения на Works в Windows (вот и Pollock загнулся недавно)...
Возможно в обозримое время мы будем реализовывать ObjectLand на другой платформе. Конечно наиболее вероятный кандидат .NET. К сожалению, все аннонсированные разработки Smalltalk под NET завершились пшиком. Какая разница, будем писать на C#, уйдут все проблемы интеграции со сторонними разработчиками и т.п.
P.S. В VSE есть портированные и юниты, и рефакторинг браузер, а также огромное количество нашего reusable кода. |
|
| | не надо уходить со Smalltalk! [ Денис ] Понедельник, 24 сентября 2007, 15:52
> В до .NET-овские времена конечно мы рассматривали VisualWorks как первого
> кандидата для портирования, учитывая неважное состояние Digitalk и затем
> ParkPlace. При всей развитости VisualWorks нас останавливали прежде всего
> проблемы пользовательского натив-интерфейса приложения на Works в Windows
> (вот и Pollock загнулся недавно)...
> Возможно в обозримое время мы будем реализовывать ObjectLand на другой
> платформе. Конечно наиболее вероятный кандидат .NET.
- А чем не устраивает связка VW + ObjectStudio? Тем более, что с выходом восьмерки эта связка становится практически "бесплатной" (в плане простоты сопряжения).
- Зачем вообще нужен нативный интерфейс?!? В форуме я, вроде, видел вопросы насчет Linux... Надо много-много раз подумать, прежде, чем жертвовать (бесплатной) портируемостью ради чего-то там...
- Кстати, а ради чего именно? В чем вообще смысл перехода со Smalltalk на что-то другое вообще? В плане разработки это откат как минимум (в зависимости от выбора "новой" платформы) лет на 10 -- 15 назад.
- ("Анекдот" в тему) Одно из направлений деятельности нашей фирмы --- ГИС. Часть команды занимается разработкой под мобильные устройства (наладонники и т.п.). Помучившись несколько лет с .NET (т.е., накопив определенный опыт) они совсем недавно решели "переползать" под обычный, не-managed C/C++. Что-то не очень им пришелся по душе .NET :) В первую очередь, конечно, вопрос в скорости. Но, думаю, если бы C# (или другой доступный язык) имел какие-то преимущества перед обычным C++, то вряд ли это стали бы делать.
В общем, если не сложно, поделитесь, пожалуйста, опытом/соображениями по поводу причин ухода со Smalltalk на что-то другое.
> К сожалению, все аннонсированные разработки Smalltalk под NET завершились
> пшиком.
И это вряд ли говорит в пользу .NET...
> Какая разница, будем писать на C#,
Ой, разница есть... :) У нас есть опыт проф. программирования и на C++, и на C#, и немного на Java, и на Smalltalk. И мы все вместе считаем, что она (эта разница) реально существует! Наш опыт однозначно говорит, что простота и динамичность языка + удобство среды = скорость разработки и развития с лихвой перекрывают то, что могут дать mainstream технологии. Если, конечно, вообще есть возможность Smalltalk применить (а вот это не всегда).
> уйдут все проблемы интеграции со сторонними разработчиками и т.п.
А какие это проблемы?
> P.S. В VSE есть портированные и юниты, и рефакторинг браузер, а также
> огромное количество нашего reusable кода.
Тогда вообще не понимаю... Мы вот обрадовались, что дело Smalltalk живет :), а тут такой непонятный поворот... |
|
| | [ ObjectLand Development Team ] Понедельник, 24 сентября 2007, 18:00
Еще никто никуда не идет... :)
Мы одна из старейших в России команд, пишущих на Смолтоке, и конечно мы поклонники этого языка. Можно сказать, что если мы бы затеяли в свое время этот продукт на C - мы бы загнулись, не породив ни одной законченной версии. Конечно Смолток тут лучше, концетрируешься на архитектуре, а не бесконечной отладке. Но имея на протяжении 14 лет коммерческий продукт, кучу пользователей и т.д. мы должны выбирать между своими пристрастиями и развитием продукта.
Поэтому не цепляемся за Смолток, хотя если бы он был под NET мы бы написали весь UI на нем (позднего связывания было бы достаточно), а все ядро на C#. В нашем случае важно использовать инструмент с развитой инфраструктурой и своевременной поддержкой новейших технологий. Как ни крути, этого нет ни у одного вендора Смолтока. А какой конкретно язык, не столь важно, важно что у смолтокеров есть объектно-ориентированный стиль мышления. |
|
| | Предложение по графическому движку [ ViFIZEG ] Понедельник, 14 апреля 2008, 17:59
| а нельзя ли для биплана вставить переменные типа площадь и периметр например %_square% будет давать площадь селектированного объекта аналогично и для периметра... а то забивать в таблицы патом в поля черезчур хлопотное дело для большого количества объктов... |
|
| | [ ObjectLand Development Team ] Вторник, 15 апреля 2008, 11:41
>а нельзя ли для биплана вставить переменные типа площадь и периметр...
Мы рассмотрим этот вопрос. |
|
| | [ Макс ] Четверг, 17 апреля 2008, 08:12
а нельзя ли для биплана вставить переменные типа площадь и периметр например %_square% будет давать площадь селектированного объекта аналогично и для периметра... а то забивать в таблицы патом в поля черезчур хлопотное дело для большого количества объктов...
Поддерживаю полностью гражданина Vifizega, давно пора. |
|
| | [ Николай Гипский ] Четверг, 17 апреля 2008, 14:31
| Да и наткнулся в очередной раз в каталоге координат (который модулем отдельным устанавливается) в МСК обрезает знаки. Исправить бы.... |
|
| | [ ObjectLand Support ] Четверг, 17 апреля 2008, 15:14
| Это у Вас старая версия приложения, нужно использовать версию Crdcatlg310.exe. Высылаю на Вашу почту. |
|
| | Предложения для ол [ ObjectLand Support ] Пятница, 18 апреля 2008, 12:21
Выложили более свежую версию, которую можно скачать по адресу http://www.objectland.ru/downloads/CrdCtlg_330_forOL_2.6.exe
В папке %OBJECTLAND%\APPS появятся reg-файлы, с помощью которых можно настроить количество знаков после запятой:
Настройка количества десятичных цифр Для настройки количества выводимых в значениях координат, длины и площади десятичных цифр необходимо отредактировать и установить файл CrdCtlg_OwnerParams.reg. Для сброса установок и использования умалчиваемых параметров необходимо установить файл CrdCtlg_DefParams.reg. Установка reg-файлов выполняется путем их запуска через Проводник или любой другой файловый менеджер.
Формат задания строки параметров
CoordDecimalDigits=<1>;LengthDecimalDigits=<2>;SquareDecimalDigits=<3>
где
<1> - количество десятичных цифр в значениях координат или пустая строка для использования умалчиваемого значения. Умалчиваемое значение для количества десятичных цифр в значениях координат равно 2;
<2> - количество десятичных цифр в значениях длины или пустая строка для использования умалчиваемого значения. Умалчиваемое значение для количества десятичных цифр в значениях длины равно 3;
<3> - количество десятичных цифр в значениях площади или пустая строка для использования умалчиваемого значения. Умалчиваемое значение для количества десятичных цифр в значениях площади равно 6.
|
|
| | Предложение по графическому движку [ Пользователь ] Суббота, 26 июля 2008, 01:51
| Почему на странице "Скачать" нет "Каталога координат"? Ссылка на скачивание только в этой теме форума? |
|
| | [ ObjectLand Support ] Понедельник, 28 июля 2008, 14:37
>Почему на странице "Скачать" нет "Каталога координат"? Ссылка на скачивание только в этой теме форума?
Мы считаем это приложение атавизмом и советуем пользоваться "Планом границ". Но для тех, кто привык к нему, продолжаем рассылать. |
|
| | [ Пользователь ] Понедельник, 28 июля 2008, 19:49
Почему при выборе в меню пункта "Каталог координат" выдается ошибка
"asCollectionOfQuotedSubstrings:separatedBy:" not understood
Windows Vista
OL 2.6.9
Каталог Координат 3.30 |
|
| | Предложения для ол [ ObjectLand Support ] Вторник, 29 июля 2008, 12:34
2Пользователь: По той же ссылке теперь исправленный вариант приложения.
Спасибо за находку! |
|
| | Предложения [ Константин Вязников ] Вторник, 7 октября 2014, 13:23
Добрый день!
Возможно ли доработать модуль "Каталог координат", в части выгрузки координат в таблице exel?
Заранее спасибо. |
|
ОтветитьЗнаком «*» отмечены обязательные для заполнения поля. |
| |
