MicroGIS™ DevCon

User_tester, спасибо! Вот только действительно не работает.
Тогда обращаюсь к разработчикам с соответствующей хотелкой. При этом прошу обратить внимание на правильность нарезки северных квадратов, которые по номенклатуре объединяются по два, а в самых северных широтах по 4. ГПСМапЭдит, например, делает нарезку северных квадратов не корректно.

DarkDiver писал(а):Чет я наверное туплю, но ни как не могу найти где запрятана нарезка карты на несколько файлов по номенклатуре, такой инструмент вообще есть?
Если нет, то очень нужен.

Пока не делали. Так как по какой номенклатуре? По союзовской генштабовской? Кого это заинтересует? Двух-трех человек раз в сто лет? По картам Jeppessen??? По морским международным (точно не знаю, но думаю, что у них то же что-то есть как в авиации Jeppessen). В общем пока не понятно как резать.

Почему бы не добавить сразу множество вариантов - на выбор.
Я, например, частенько пользуюсь этой функцией. Предлагаю сделать на выбор нарезку либо по номенклатуре, или по нескольким номенклатурам, либо с произвольным шагом задаваемым пользователем, например: 1град. X 1град. или 10'x10'. В первую очередь я имел ввиду конечно же генштабовскую номенклатуру. Живем на территории советского союза, в качестве исходных данных используем в том числе и генштабовские карты - поэтому инструмент нужный.

Размер топографической карты, например, хабаровского края ~1,5GB без рельефа, и 8 GB - с рельефом сгенерированным по SRTM, а если делать рельеф из ASTER DEM, объем еще раза в два - в три возрастет. Поэтому карту приходится нарезать.

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

Скриншот.

Так и должно быть. Ибо считается ошибкой: когда линия замыкается сама на себя. Так было всегда, так и задумывалось.


MicroGISEditor обновление v1.0.11.568b

Спасибо за обновление. Как оказалось, у меня у многих НП не стоит галка Индексировать как НП. Для СитиГИДа это не нужно. Я верно понимаю, для того что бы исправить ошибку надо в таблице всем проставить галку Признак города ?

Да, достаточно
Fencer_silver

Добавлено спустя 6 минут 5 секунд:
И второй вопрос. На закладке Дерево вверху пишется кол-во ошибок. Как их посмотреть ? Красным не подсвечено ничего.
Доделаю - этот инструмент делался впохыхах
Fencer_silver

Обновление хорошее, спасибо!

Пару замечаний.

1. Найти - нашли. Красных строк может быть много. Только надо как-то облегчить процесс исправления ошибок. В проверках карты не хватает соответствующих проверок! Сейчас у меня в дереве 9 ошибок, а проверка почтовых адресов выдаёт 0 ошибок.

Всё ошибки, которые находят дерево и любые другие "модули" программы, должны отражаться в виде соответствующих проверок в центральном модуле "Проверка карты на ошибки".

2. Из дерева отцентрироваться на красных строках на карте не получается. Приходится возвращаться на соседние вкладки городов для нахождения там "красных" объектов. А чаще всего - в панель поиска объектов на карте. Находить оттуда. И затем пробовать понять, какая же ошибка из перечисленных:

Alex писал(а):Ошибками считаются:
- наличие в базе данных населенного пункта, не имеющего привязанное ПОИ из категории "Населенные пункты";
- привязанное ПОИ, но с неустановленным маркером "Индексировать как населенный пункт";
- дороги, с различными наименованиями и улицей;
- дороги, не имеющие улицу.

в каждом из них присутствует!

В панеле поиска - доделаем соответствую щие проверки, и они будут жить отдельно. Этот инструмент был срочно прикуручен - для экспресс - проверки карт, когда их много, открываешь одну - за одной - и быстро проверяешь только адреску. Обращаю внимание, в дереве адресов легко находятся такие ошибки (визульно, без подсвета красным), как "ул. Ленина", "Ленина" "Ленина ул." и т.д.
Fencer_silver

Объясните пожалуйста, что означают понятия внутренних нодов в описании таблиц изолированного рафа ? В инструкции пишется так:
Буква "в" означает наличие внутреннего NOD,
Буквы "вв" означают наличие 2-х внутренних NOD
Зачем это вообще надо и почему может быть только 1 или 2 внутренних нода ? И какие ноды считаются внутренними ?

Макс.... ты меня пугаешь. Звони на скайп... или кури мануал...

Ошибка пересчета координат из Pulokovo 1942 в WGS84.

Как известно, в польском формате используется система координат WGS84 Latitude/Longitude.
При создании карт мы используем различные данные, как растровые так и векторные, которые иногда привязаны в других системах координат, в том числе Pulkovo 1942. Вот здесь выложил архив со всеми исходными данными и результатами экспериментов, демонстрирующих проблему:
http://www.sendspace.com/file/bn5uiq
Ниже по тексту я буду ссылаться на файлы и папки из этого архива.

Исходные данные:
1. Shape файл с номенклатурными полигонами в системе Pulkovo 1942: \src-shape\topo1km-rus.shp
2. Растровые карты генштаб и госгисцентр: \raster\K-53-004-C-c.png, \raster\K-53-004.jpg
3. Треки: \Tracks\*.gpx

Программы:
1. Global Mapper v13.1 и v14.0 – далее по тексу GM
2. MicroGisEditor – далее по тексту MGE.

Эксперимент:
1. Открываем shape файл с номенклатурными полигонами в Global Mapper. Датум и систему координат GM подхватывает автоматом из идущего в комплекте с шейпом файла *.prj, вручную указывать нет необходимости (см. \screens\screen0.jpg). Кстати было бы не плохо сделать так же и в MGE.
2. Для дальнейших экспериментов нам не нужны полигоны на весь земной шар, поэтому оставим только несколько полигонов и сохраним шейп-файл как: \result\100k-test.shp
3. Экспортируем получившийся шейп в польский формат как: \result\100k-test2.MP
4. Закрываем Globla Mapper и запускаем заново – для чистоты эксперимента.
5. Открываем в GM файл: \result\100k-test2.MP
6. Затем добавляем шейп: \result\100k-test.shp
7. Затем открываем один из растров: \raster\K-53-004-C-c.png
8. Смотрим границы обоих файлов и границы растра – все прекрасно совпадает – так и должно быть (см. \screens\screen1.jpg).
При этом система координат в которой привязан шейп: S-42 (PULKOVO 1942), Geographic Latitude/Longitude (см. \screens\screen2.jpg)
Система координат в которой отображаются данные: WGS-84, Geographic Latitude/Longitude (см. \screens\screen3.jpg)
9. Теперь открываем в MGE файл: \result\100k-test2.MP тип полигонов – 0x1.
10. Затем импортируем в MGE шейп: \result\100k-test.shp. Указываем датум Pulkovo 1942 (GOST R…..) и систему координат Latitude/Longitude. Указываем тип 0x6. Сохраняем результат как \result\bug.mp.
Смотрим стыки полигонов – видим что стыки полигонов 0x1 и стыки полигонов 0x6 не совпадают, имеется сдвиг примерно на 20-25 м. (см. \screens\screen4.jpg)
11. Подгружаем в MGE растр: \raster\K-53-004-C-c.png
В результате видим, что границы растра прекрасно совпадают с границами импортированными из шейпа, что логично, шейп и растр в одной системе координат и в WGS84 MGE их пересчитал одинаково. Но не совпадают с границами из GM (полигоны 0x1), хотя в GM все совпадало. (см. \screens\screen5.jpg)
12. Отсюда вывод: GM и MGE выполняют пересчет из Pulkovo1942 в WGS84 по разному.
Вопрос какая из программ делает это правильно, а какая нет? Ответить на него нам помогут треки. Это могут быть например треки какой-нибудь дороги, желательно, чтобы их было несколько. В папке \Tracks\*.gpx хранится как раз такой набор из четырех треков одной и той же дороги, записанных двумя навигаторами.
13. Подгружаем в MGE треки, и видим что они смещены относительно растра примерно на те же 20-25 метров. (см. \screens\screen6.jpg)
14. Открываем тот же растр и те же треки в GM – треки идеально ложатся на растр. (см. \screens\screen7.jpg)

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

Из всего сказанного делаем вывод: пересчет координат из Пулково в WGS84 выполняется не корректно.

Такая систематическая погрешность в 20-25 метров не критична и не заметна при работе двухкиломтеровками и более мелкими масштабами. При работе с километровками эта погрешность уже заметна, но не сильно критична. При работе с 500-метровками, и тем более с 250-метровками данная погрешность уже слишком значительна.

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

Имеющийся инструмент "Создать POI в строениях" работает некорректно, не в соответствии со своим названием и описанием в мануале. Он создаёт POI абсолютно во всех полигонах, а не только в строениях, как написано.

Имеет ли смысл постановка POI во все полигоны? Неужели есть конечные форматы карт, в которых даже полигоны лесов и морей имеют адреску, переносимую картографом в POI? Сомнительно это.

не понимаю... что делаю не правильно.

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

Даже не знаю как это назвать баг или хотелка.

При трансляции ПОИ в шейпы не учитывается поле "HouseNumber".

То бишь переносится только улица, а номер выпадает. Так вот, возможно ли в атрибут STRT_ADDR шейпов для ПОИ объединять атрибуты "HouseNumber " и "StreetDesc".

Замечания по функции "Выделить объекты по типу и пересечению" (MGE 1.0.11.568 + Win 7)

Объекты не выделяются как пересекающиеся в следующих случаях:

1. Если линейные объекты пересекаются и имеют в точке пересечения совпадающие вершины (первый сверху пример в прилагаемом исходнике).

2. Если линейный и полигональный объекты стыкуются по строго по вершинам, например:

а) линия границы по периметру оконтуривает строго по вершинам полигон покрытия карты (второй сверху пример)

б) забор целиком оконтуривает промзону или только какую-то её сторону (третий сверху пример)

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

4. Точечные объекты POI с совпадающими координатами. То есть, лежащие друг на друге стопкой (пятый сверху пример).

P.S. Немного пояснения:

а) Два объекта пересекаются, если хотя бы одна вершина одного из них совпадает в своих координатах с любой вершиной другого объекта.

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