MicroGIS™ DevCon

User_tester писал(а):

Monstria писал(а):Если удаляется основная дорога (дорога с заполненными адресными атрибутами) - проверять не ссылаются ли на них адресные точки, и если ссылаются - автоматом искать замену.

Была улица Ленина. Её ликвидировали. Не понятно, какую замену адресам в точках можно найти, да ещё автоматом (т.е. без участия пользователя!), если ул.Ленина уже нет? Нужно предупреждение в этом случае. И соответствующая проверка карты, наверное.

В большинстве случаев удаляется не вся дорога целиком, а один из её отрезков. но на эти отрезки могут ссылаться адресные точки.
Соответственно следует проверить если ли ссылки адресных точек на данный участок удаляемой дороги, если есть, найти ближайшую дорогу с однотипными адресными данными и перелинковать на нее адресные точки.
Если же по близости (в своих алгоритмах я использую радиус 10 км) нет подходящих дорог - то соответственно предупредить пользователя.

User_tester писал(а):

Monstria писал(а):Если основная дорога (дорога с заполненными адресными атрибутами) переименовывается пользователем и на нее есть ссылки адресных точек - предупреждать пользователя, т.к. возможно будут допущены ошибки, которые компилятор пропустит, и выявить их крайне сложно

Аналогично. Улицы часто переименовывают. Как быть, если улицу мне приходится переименовать? Ну получу я предупреждение. Но ведь надо не просто предупреждать, а как-то решать проблему. Или автоматом, без участия пользователя, переприсваивать улицу в адресных точках, или в табличном режиме их надо будет мне поправлять.

Абсолютно верно - аналогично... Но если вы переименовали дорогу на которую есть ссылки адресных точек - так же меняется и результат поиска в навигаторе, а вот семантика зданий, номеров домов остается без изменение. Причем изменение названия дороги не вызовет ни каких претензий компилятора - все как бы штатно, а на деле получим разницу адресов и семантики - стоит перепроверять данный случай, так как искать ошибки адресов в навигаторе - довольно таки сложно. Поэтому необходимо предупредить пользователя, заодно показав затронутые этим изменением объекты (контуры домов, номера задний) (кстати - это у меня, в программе,это не реализовано пока, записано только к реализации, но будет сделано обязательно, потому как постоянно натыкаюсь на эти грабли)

Добавлено спустя 2 минуты 53 секунды:
Ну а как решать проблему - тут уже не меня спрашивайте, а разработчиков... вариантов может быть масса, что реализовать - родится из прений. Я лишь указываю на узкие места, с которыми я сталкивался в свое время.

Загруженный растр jpg с привязкой map отображается только при большом увеличении (от 1:5300). Один растр 7275х8808 px загружается нормально, для второго такого уже не хватает памяти (WARNING: Not enough video memory to render image.). Но в предыдущих версиях растр такого размера не загружался вообще. После выгрузки первого файла, другой уже не загружается. Видеопамяти 512 мб (мапэдит грузит до 3 таких файлов).
ECW в 10 раз больше по площади грузится мгновенно (нет только возможности посмотреть размер и разрешение растра для ECW).
Еще есть баг - если выделить любой растр и нажать Del - появляется ошибка MGE v1.0.11.572b + WinXPx32

За ошибку, спасибо, буду смотреть. Пробовали на Win7 64 бита 8 ГБ оперативки - загрузили 100 растров 5000x5000.
Здесь важна оперативка.

А для ECW - у нас ограничения практически отсутствуют.

Fencer_Silver писал(а): Здесь важна оперативка.

4 Гб на WinXPx32 - грузится только один файл. Запущенный без карты MGE по диспетчеру задач занимает ~90 Мб памяти, при загрузке первого растра (jpeg 7275x8808, 23 мб) использование памяти возрастает до ~700 мб и падает до 96 мб после отрисовки растра; при попытке добавить второй растр использование памяти растет до ~310 мб и возвращается до 100 мб, причем выдается ошибка про нехватку видеопамяти.

Monstria, мне понравились описанные вами мысли касательно точек адресов/подъезда.

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

От себя добавлю, что хорошо бы иметь такие проверки:

1. проверку карты на присутствие в карте актуальных LINK_ID дорог, на которые ссылаются ADDR_PNT (на случай удаления дороги).

Если перелинковку можно как-то автоматизировать частично или целиком, как и порезку дорог на перекрёстках, то было бы неплохо. Но проверка такая всё равно будет нелишняя! Она информативная и позволит пользователю все ошибки видеть своими глазами и анализировать.

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

Как удобный вариант, в полигон дома вспомогательным ключом вписывать все LINK_ID от ребёр улицы, к которой принадлежит дом. Делать это автоматом прямо на стадии отрисовки домика, когда мы выбираем ему улицу.

Например, выбрали улицу Ленина - значит, в домик программа вписала StreetDesc=Ленина, а также LINK_ID=1,4,6,15,17. В Label можем записать "Ленина, 2".

И потом сделать проверку карты. Проверять идентичность улицы в доме названиям улицы в рёбрах, привязанных к дому по указанным LINK_ID. Если какое-то ребро переименовано - например, LINK_ID=6 стало улицей Кирова, то предупреждать об этом пользователя и выделять дом и ребро на карте. Пользователь будет решать, какую улицу теперь вписать в домик и в его лабел - старую Ленина или новую Кирова. И соответственно, в домике обновятся LINK_ID!

Если все рёбра переименовались, то проверка выдаст предупреждение о несоответствии наименований, и придётся обновить улицу в домике.

P.S. Как пример - у нас в 2005 г. было одномоментное фееричное переименование:

проспект Машерова переименован в проспект Победителей,
улица Варвашени - в проспект Машерова,
улица Енисейская - в улицу Варвашени



А теперь представьте, сколько надо перелопачивать зданий, ведь названия старых улиц фактически никуда не пропали и редактор их не различит... Но их местоположение в городе сильно поменялось!

А групповая таблица зачем? там все переименовать можно за 5 мин.

User_tester писал(а): 1. проверку карты на присутствие в карте актуальных LINK_ID дорог, на которые ссылаются ADDR_PNT (на случай удаления дороги)....

У меня сделана утилита проверки, ровно как и на соответствие семантики дорог и домиков, номеров домиков

User_tester писал(а): 2. чтобы не потерять актуальность семантики в полигоне дома при переименовании улицы, надо их связать....

Я думал про это тоже, но оказалось штатными средствами арка править это очень легко - поэтому не заморачивался. Если в MGE уже реализована поддержка микроскриптов - то править там тоже особого труда не составит..

User_tester писал(а): А теперь представьте, сколько надо перелопачивать зданий, ведь названия старых улиц фактически никуда не пропали и редактор их не различит... Но их местоположение в городе сильно поменялось!

Ну если будет создана утилита проверки - уже все станет намного проще

Добавлено спустя 55 секунд:

Fencer_Silver писал(а):А групповая таблица зачем? там все переименовать можно за 5 мин.

Нужно что бы правило в этой таблице на основе скрипта, например меняло часть строки...

3. Далее мысль: сейчас в программе есть функция создания POI в строениях. Правда, работает она как-то странно - ставит безымянные (тип=0) POI не только в зданиях, а везде во всех полигонах. Сомнительно, что в таком виде эта функция полезна. Было бы здорово её переиначить на массовую постановку ADDR_PNT по центру полигонов с адресами. И добавлять в ADDR_PNT адрес из полигона.

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

Если в здании адресных данных нет или они неполностью заполнены (чего-то отсутствует), то такие здания пусть функция игнорирует и ничего на них не ставит.

Соответственно, в шейпы попадут только правильно сделанные здания и соответствующие им точки.

Нужно что бы правило в этой таблице на основе скрипта, например меняло часть строки...

У нас есть замена подстроки.

1. Тип кары топо, в Гармине все без проблем.
2. Полигон и время работы с картой не имеет значения. Тип линий пробывал, гос границу планируемый маршрут и граница гор района (чтоб были яркие и не потерять в карте) после преобразования полигона в полилинию и смене типа на данный, ошибка. Если выбрать сразу тип линии роутовой (дороги) то ошибки не возникает. Если изменить на роутовый тип после данных полилиний то ошибка все равно выползает.
3. Воспроизводится регулярно и после удаления всех ини.

Monstria писал(а):Если в MGE уже реализована поддержка микроскриптов

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

User_tester писал(а):

Monstria писал(а):Если в MGE уже реализована поддержка микроскриптов

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

Вы делитесь скриптами для WEB сереров изображений, что помешает делиться скриптами решающие различные задачи? Это только кажется что все сложно - обычно скриптовый язык довольно таки простой, с ограниченным набором функций, в которых разобраться особого труда не составляет даже не программисту - было бы желание... ИМХО

messer2006 писал(а):1. Тип кары топо, в Гармине все без проблем. 2. Полигон и время работы с картой не имеет значения. Тип линий пробывал, гос границу планируемый маршрут и граница гор района (чтоб были яркие и не потерять в карте) после преобразования полигона в полилинию и смене типа на данный, ошибка. Если выбрать сразу тип линии роутовой (дороги) то ошибки не возникает. Если изменить на роутовый тип после данных полилиний то ошибка все равно выползает.3. Воспроизводится регулярно и после удаления всех ини.

Теперь подтверждаю, проблема есть. Ранее я проверял в тайпсете Гармин - там не видел.

1. Но в ТОПО у меня воспроизводится не на всех типах.

Проблемная комбинация: гаражи (0х0006) ---> граница района округа (0х001D).

Нормальная комбинация, например: гаражи (0х0006) ---> просека (0х0048).

2. И отличие ещё в том, что адрес в ошибке у меня 00000050, а у вас 00000078.



Добавлено спустя 14 минут 49 секунд:
Monstria, а что думаете по поводу массовой расстановки пар точек по полигонам с адресами? Мне представляется удобно. Тем более, функция подходящая для доработки уже есть.

Так я и писал про роутовые к коим просека и относится.

User_tester писал(а): Monstria, а что думаете по поводу массовой расстановки пар точек по полигонам с адресами? Мне представляется удобно. Тем более, функция подходящая для доработки уже есть.

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

PS... у меня много что вкусного реализовано - многими идеями я делился, много что можно посмотреть на ютубе - мне моих идей не жалко - Александр и Сергей частенько заимствуют понравившееся