Обсуждение Beta версий (тестирование, баги, замечания)

[Evlampiy]

Fencer_Silver Начальника, не кричи

Из-за этого Ваши дома покрутило?

Не только у меня

Общался на эту тему с товарищами, у них такая же ерунда - не переходят на МГЕ из-за этого. И меня это тормозит кардинально.

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

[Fencer_Silver]

Появилось неудобство: рисую здания с адреской, включен автоинкремент. Номер здания (Лабел) отрисовывается только после снятия выделения нарисованного, нажатия кнопок в меню... Раньше отрисовывалось сразу.

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

Не только у меня

Это из-за различий в 5-й цифре после запятой - около 3-х метров. Это- уже серьезно.

Добавлено спустя 4 минуты 46 секунд:

Общался на эту тему с товарищами, у них такая же ерунда - не переходят на МГЕ из-за этого. И меня это тормозит кардинально.

Ну, совместимости никто не обещал. Могу сказать одно - при работе только в МГЕ - ничего не крутит. К сожалению, работа в двух редакторах одновременно - невозможна. Насколько знаю - те же проблемы есть при работе в ГМЕ и ГМЕ++.

Чуть позже попробуем расширить битность в карте. Как следствие - повышение точности. Однако нет никакой гарантии, что это решит проблему.

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

Сделаем, все Step-By-Step. На все сразу -нет времени.

Добавлено спустя 3 минуты 33 секунды:

Такая строка несвойственна для формата TYP, поэтому, например, TYPViewer при редактировании заменяет эту строку ("StringMPCName=0x04,###") на "String3=0x04,###".
Другой известный редактор типов TypWiz вообще удаляет эту строку при редактировании, даже если предварительно "StringMPCName" заменить на "String3" по аналогии с TYPViewer.
Так что, надо что-то другое придумать...

Так пусть останеться "String3=0x04,###". Какие еще предложения?

[User_tester]

Чуть позже попробуем расширить битность в карте. Как следствие - повышение точности.

Будет отлично! Я специально рисую в битности 26, но выставлять её мне приходится через блокнот Notepad++. Если можно будет ставить через "Свойства карты", буду только рад удобству. Дома у меня ровные и красивые. Такими же остаются после компиляции.

Насчёт ваших кривых домиков, перекручиваний, сползаний и прочих смещений координат - у себя такого пока что не наблюдал. Хотя я рисую исключительно в микрогисе, а в мапэдите специально ничего открываю и не правлю. Все удобства и функции, что мне недостаёт в МГЕ, пишу в хотелках.

Карту в МГЕ удаётся согласовать по DATA_BOUNDS и скомпилировать вместе несколько кусков. Роут при этом не рвётся. Это та самая геморная работка, которую до сих пор делали в аркгисе...

Может, стоит выбрать окончательно 1 из двух альтернативных редакторов польского (МГЕ/ГМЕ) и уже не дёргаться в другую сторону, раз у вас наблюдаются такие косяки? Тем более, что на данном этапе микрогис уже далеко не такой, каким был в начале 2012 года, а достаточно выверенный и строгий.

[Alex]

Такая строка несвойственна для формата TYP, поэтому, например, TYPViewer при редактировании заменяет эту строку ("StringMPCName=0x04,###") на "String3=0x04,###".
Другой известный редактор типов TypWiz вообще удаляет эту строку при редактировании, даже если предварительно "StringMPCName" заменить на "String3" по аналогии с TYPViewer.
Так что, надо что-то другое придумать...

Ну это понятно, что запись вида: "StringMPCName=0x04,###" не понимается TYPViewer.
А кто мешает потом "String3=". заменить на "StringMPCName=" например в Notepad++???

На всякий случай скажу:
- String1=, String2=, String3= --- строки с названием объекта на разных языках;
- StringX=00...22 - код языка;
- MicroGISEditor в TYP файле, поддерживает только один язык и соответственно берёт только запись вида StringХ=, стоящую первой (например String1=). Данные попадают в колонку "Описание" (название типа); Поэтому в I0000001.txt String1=записана на английском (чтобы англоязычные пользователи видели названия вместо козликов). Остальные записи: String2=, String3= - игнорируются.

- StringMPCName= служит, для заполнения колонки "MPC наименование" и участвует при экспорте в шейпы.

[AleksandrD]

Появилось неудобство: рисую здания с адреской, включен автоинкремент. Номер здания (Лабел) отрисовывается только после снятия выделения нарисованного, нажатия кнопок в меню... Раньше отрисовывалось сразу.

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

Раньше отрисовывалось сразу - это точно: нарисовал полигон - сразу лабель на нем появилась. Если ненапряжно сделайте - буду благодарен.

[Cnfhbr]

Так пусть останется "String3=0x04,###". Какие еще предложения?

Дело в том, что если пользователь при первом редактировании в TYPViewer добавит названия данных кастомных объектов на других языках, то эта нестандартная строка примет уже иной вид - String4, String5 и т.д., в зависимости от количества добавленных языков...

Ну это понятно, что запись вида: "StringMPCName=0x04,###" не понимается TYPViewer.
А кто мешает потом "String3=". заменить на "StringMPCName=" например в Notepad++???

Можно, конечно, после каждого редактирования в TYPViewer, не забывая, корректировать эти строки в Notepad++ заменой, но это только для поклонников TYPViewer'а.
А, что делать тем, кто редактирует типы посредством TypWiz, который просто удаляет эти нестандартные строки при редактировании? В том же Notepad++ восстанавливать всё ручками для 3079 объектов после каждого редактирования?

По-мне, так и вариант с hex-кодами был вполне приемлем, однако теперь народ просит даже редакторы типов модифицировать ради этого тип-файла (Ссылка).

P.S. По ходу обнаружил ошибку в I0000001.txt, см. кастомную дорогу (0x11) - лишняя закрывающая квадратная скобка в начале строки - ]StringMPCName=0x04,CUSTOMIZABLE_ROUTE_LINE_5

[Vovan_Alm]

А по другому никак? Может не портить исходник typ файла? Его же можно использовать для Маппера, и большой вопрос как маппер отнесется к строчке StringMPCName=0x04,CUSTOMIZABLE_ROUTE_LINE_5? Может все-же ввести человеческую таблицу перекодировки, пусть даже перекодировка работает до Шейп Файлов... Я согласен, даже на то что не будет прямой подмены (по сути что так, что так, а на выходе будет одинаковый вариант, а если так то зачем из-за этого воевать), хотите что бы все было по линейке и побелено как в армии, пусть будет так... Но мне категорически не нравятся десятичные типы в колонке Идентификатора Гармина. Как мне видится - это должен тестовый файл примерно такой

Код: Выделить всё

0х0ХХХ -RL - CUSTOMIZABLE_ROUTE_LINE_ХХХ

где 0х0ХХХ десятичный код
RL - идентификатор что объект Роутовая Дорога
CUSTOMIZABLE_ROUTE_LINE_ХХХ - идентификатор Гармина (С ВОЗМОЖНОСТЬЮ ЗАМЕНИТЬ ЭТО НАЗВАНИЕ НА ЧТО УГОДНО типа ZHELEZNAYA_DOROGA) и этот пункт меню РАЗМЕСТИТЬ НА ЛЮБОМ МЕСТЕ МЕНЮ ПЕРЕВОДА В ШЕЙПЫ...
Притом тем, кто уже настроил редактор под десятичные типы, просто не делайте преобразование типов, перед изготовлением в шейпов - и вам ничего менять не нужно...
ВСЕ СОГЛАСНЫ? Возражения Есть?

[KartaBY]

Хрень какая то с редактором.
- открыл карту, нарисовал перекресток
- нарисовал движение по полосам, расставил запреты (сложные, по времени и транспортным средствам)
- сохранил
- вышел из редактора
- загрузил редактор, загрузил карту

1. из четырех узлов на перекрестке движение по полосам осталось только на одном узле, остальные слетели, при этом количество рядов осталось.
2. слетели запреты

[KartaBY]

Не знаю, верно ли я разобрался, но похоже редактор похерил движение по полосам из-за наличия односторонненго движения в линиях.

Код: Выделить всё

Only used when creating lane connections. Indicates the number of road lanes when traveling from the last vertex to the first vertex. Only applicable if ONE_WAY is not set to 1 or Y. 

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

[vad47]

Довольно давно приглядываюсь к вашей программе. Главный сдерживающий фактор - плавающая запятая. Не раз приходилось обжигаться с полигонами в старом ГМЕ, когда к примеру острова съезжали со своих мест на большом полигоне с дырами. Повторять ошибки не хочется. Может дать возможность пользователю самим выбирать в настройках программы в каком виде хранить данные, с плавающей запятой или фиксированной? И по поводу совместимости. Программа может быть сколь угодно уникальной, но воплотить все функции необходимые пользователю, думаю просто невозможно. Поэтому должен быть безболезненный перенос в форматы других программ, без потери точности и самих данных. Тоже самое относится и к экспорту данных. Согласитесь, если у пользователя есть карта, будет ли он пользоваться вашим редактором, если тот заведомо вносит хоть и не большие, но искажения?

[User_tester]

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

Ну так Гармин же практически полностью поддержали! Это как пример. И экспорт в шейпфайлы для него прекрасно работает. Осталось доделать немногое... И будет всё супер для гарминовцев

Но у Гармина есть чёткий мануал и устоявшаяся структура. А насчёт других систем, то многое здесь, наверное, зависит и от обратной связи "производитель навигационной системы" ---> "разработчик редактора МГЕ". Важно, чтобы и там успевали подтягиваться и всё согласовывать. До того, как что-то добавят в навигационную систему, рисовальщики это не попросят поддержать.

[Alex]

Не знаю, верно ли я разобрался, но похоже редактор похерил движение по полосам из-за наличия односторонненго движения в линиях.

Код: Выделить всё

Only used when creating lane connections. Indicates the number of road lanes when traveling from the last vertex to the first vertex. Only applicable if ONE_WAY is not set to 1 or Y. 

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

Запрет и есть явный, присмотритесь к рисунку. Если дорога с односторонним движением (флаг "Одностороннее движение") - полосы на встречу - не создаются. Вероятно вы не разобрались.

Довольно давно приглядываюсь к вашей программе. Главный сдерживающий фактор - плавающая запятая. Не раз приходилось обжигаться с полигонами в старом ГМЕ, когда к примеру острова съезжали со своих мест на большом полигоне с дырами. Повторять ошибки не хочется.

Проблема которая была в ГМЕ - никак не связана с проблемой обсуждаемой здесь. В МГЕ наблюдается допустимое "сползание" координат на приблизительно 19см. Но это никак не может повлиять на скручивание домиков.

Может дать возможность пользователю самим выбирать в настройках программы в каком виде хранить данные, с плавающей запятой или фиксированной?

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

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

Функции нужные пользователю - вопрос риторический. У нас в листе хотелок, столько "НУЖНОСТЕЙ" (в том числе и абсурдных), что лет на 100 хватит целому отделу. Конечно все желания - поддержать не возможно. Но мы стараемся.
А вот насчет поддержки формата, полей, атрибутов - это совсем другой вопрос. Мы стараемся поддержать всё в полном объеме. На сегодняшний день, нами поддержаны все типы и параметры данных используемые в СитиГид, 7дорог. Вы знаете еще хотя бы один редактор, который этим может похвастаться (MapInfo и ARCGis - это другая история)? Недотянутым является только Garmin. Но мы над этим работаем, немного и осталось.

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

При экспорте, ничего не меняется. Экспортируется всё в точности, что есть в исходнике. Речь идет не об этом. Округление (в рамках допустимого) происходит при записи данных в исходник. Тут уже извините, каждая программа имеет собственный алгоритм обработки и информация не доступна для сторонних разработчиков. Поэтому, на просьбу, сделать как в ГМЕ - отвечаю, это не возможно. Потому как разработчик ГМЕ не делится информацией, ровно так же как и все остальные. У каждого свой подход и методы решения.

Согласитесь, если у пользователя есть карта, будет ли он пользоваться вашим редактором, если тот заведомо вносит хоть и не большие, но искажения?

Искажения вносят все. Кто то больше, кто то меньше, кто то в одну сторону, а кто то в другую. Методов повышения точности - много. ГМЕ решило вопрос с точностью, перейдя на фиксированную запятую, ГМЕ++ добавило 7 знак, после запятой, кто то ещё как то. С чего вы решили, что мы должны перейти на фиксированную запятую?

В любом случае, проблемы нет, но желание пользователей повысить точность - принято к сведению. Решение будет найдено. Следите за форумом.

[AleksandrD]

Групповая панель. Создаю фильтр. Первое условие = тип, равно, далее жму треугольник, ищу 0х006с (жилое здание).
До сих пор не могу понять о какому принципу сортируются типы в данном случае - тип 0х006с находится почти в конце.
Объясните плз принцип сортировки.

Добавлено спустя 12 минут 1 секунду:
По идее здания с пустым Лабел показыват не должно, или я не прав?

[_Michael_]

Пои (все типы по возрастанию кода); полилинии и полигоны, если мне память не изменяет, то в такой последовательности

[AleksandrD]

Жму "копировать номер дома в наименование" - ничего не происходит.
Просьба подтвердить это у меня глюки или у всех?

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