Re: Beta тестирование (обсуждение функционала beta версий)
Добавлено: 11 окт 2012, 13:01
Ну сделайте проверку карты на неполные адресные данные... как то надо знать в каких домах проблемы...
Technology. Security. Development. Future.
https://forum.micro-gis.com:443/
То есть, случаи:Vovan_Alm писал(а):Ну сделайте проверку карты на неполные адресные данные... как то надо знать в каких домах проблемы...
Можно подробней что Вы имеете в виду под съездами?Alex писал(а):Имелось ввиду, планируется поддержать съезды, записывающиеся в узел. Если у когото есть доп. информация по ним - высказывайтесь.[/color][/size]
Ребята, а вы вообще смотрели, что реализовано в проверках уже??? Инструменты -> Проверка карты-> Включите все опции в ветке "Почтовые адреса" -> Начать проверку. И посмотрите, что у вас в картах твориться.Vovan_Alm писал(а):Ну сделайте проверку карты на неполные адресные данные... как то надо знать в каких домах проблемы...
Проверил - у меня всё нормально! Ни одной ошибки нет!Fencer_Silver писал(а):Ребята, а вы вообще смотрели, что реализовано в проверках уже??? Инструменты -> Проверка карты-> Включите все опции в ветке "Почтовые адреса" -> Начать проверку. И посмотрите, что у вас в картах твориться.
Не, ну тут я и не сомневался....Проверил - у меня всё нормально! Ни одной ошибки нет!
Ну, и какое там противоречие? В существующем описании "польского" формата имеется ряд типов, несопоставимых для МРС, и назначение отдельных типов определено не совсем так, как в МРС - поэтому соответствие НЕ ЖЁСТКОЕ (через hex-коды, разумеется), а ЖЁСТКОЕ - только в самОм МРС.DarkDiver писал(а):Абсолютно ни чего не искажал ты просто сам себе противоречишь, сначала пишешь:а затем наоборот:Cnfhbr писал(а): В данном контексте, нет такого "стандарта" жёсткого соответствия между HEX ID типов в "польском" и GRMN_TYPE в MPCCnfhbr писал(а): ЖЁСТКОЕ соответствие этих кодов текстовым GRMN_TYPE только в самОм MPC!
Жёсткое, но не в том месте, о котором спорим...DarkDiver писал(а):Ну вот и я говорю что соотвествие жесткое, о чем мы тогда спорим?
Ну как не имеет? Я говорю, что даже в Гармине всё, что за пределами МРС, может иметь не жёсткое соответствие, такое как в МРС, например, отдельные прошивки. Ты же утверждаешь, что соответствие и там жёсткое, только лишь отображение может отличаться:DarkDiver писал(а):То что там отдельно взятыми приборами что-то там по разному трактуется, категоризируется и отображается - вообще к сути вопроса отношения не имеет...
Назначение и отображение типов - по-моему, разные вещи.DarkDiver писал(а):В прошивках разных приборов отличается не кодировка типов!!! а только способ отображения одних и тех же типов.
Вот! А я не столь категоричен в данной ситуации, поскольку не считаю соответствие типов "польский" - МРС жёстким. На мой взгляд, в условиях использования единого классификатора для маппера и МРС, у пользователя должна быть возможность перед экспортом в шейпы присвоить, например, характерному только для маппера типу, если ничего не мешает, кастомный тип МРС.DarkDiver писал(а):Дополнительно к этому я утверждаю что при экспоте из польского в шейпы, перобразование HEX ID -> GRMN_TYPE должно выполняться в точно таком же соответствии по этой же таблице!
Даже в мыслях не было делать это на этапе экспорта, да ещё и не придерживаясь классификатора:DarkDiver писал(а):Просто вопрос то принципиальный, зачем мы так долго вычищали классификатор, если на этапе экспорта ты предлагаешь его не придерживаться...
Всё сказанное касалось именно пользователя, а не алгоритма работы софта...Cnfhbr писал(а):Я вовсе не против строгого соответствия, которого мы пытаемся добиться в классификаторе Garmin! Я лишь предлагал, как устранить варнинги в логе MPC и игнорирование при компиляции несвойственных типов объектов: либо вообще не посылать на вход MPC не сопоставленные с GRMN_TYPE "польские" типы, либо предварительно сопоставить их с близкими по смыслу стандартными GRMN_TYPE, либо ассоциировать с CUSTOMIZABLE типами. Чего их солить то эти кастомные? Речь ведь о паре-тройке неопознанных в логе объектов каждой категории, заметьте, не требующих роутинга, поиска, глубины, цвета маяка и прочей хрени (всё основное у нас, слава богу, приведено в порядок). Так, если картописатель по каким-то личным мотивам захотел оставить "левый" тип в своём "полише", почему бы ему не воспользоваться кастомным от Garmin, даже если их мнимые(ИМХО) hex id не совпадают? Может ему нужно, чтобы этот объект просто присутствовал на карте без всяких там прибамбасов...
А атрибут RD_SIGNS ??? Наверное забыли.Alex писал(а): Что касается дор. знаков. Имелось ввиду, планируется поддержать съезды, записывающиеся в узел. Если у когото есть доп. информация по ним - высказывайтесь.
Про него и говорили. Он должен жить в ноде. Пока в МГЕ (да и в Мапэдите - не видел) - не сделано вообще свойство нода, определяющее этот параметр. Т.Е. нужно добавить свойство - определить ключи для записи в польский, учесть его в операция копи-паст, вычитку из польского. Вот тогда и будет поддержка этого параметра. Чем Вы его сейчас расставлять собираетесь?А атрибут RD_SIGNS ??? Наверное забыли.
Ваш - да, Мапедит - нет.Fencer_Silver писал(а): Но неизвестные секции - что наш редактор, что Мапэдит - прибивает.
Значит дотянул.Ваш - да, Мапедит - нет.
rd_signs и exit services разные вещи,если спрашиваетет то уточняйте про что.Fencer_Silver писал(а):Про него и говорили. Он должен жить в ноде. Пока в МГЕ (да и в Мапэдите - не видел)?А атрибут RD_SIGNS ??? Наверное забыли.