Создадим приличную карту Крыма!

[SergeyV]

(-)

[Bushman]

Если раскидывание по слоям и прочее - последний этап, что привязываться к MapEdit ни к чему особенно.

[denisxor]

Как мы уже обсудили в личной переписке, так и стоит поступить. Написать спецификацию будет намного проще когда будет конкретный готовый кусок + его обсуждение. Гениев мало, а коллективный разум рулит... Поэтому после подготовки карты "нулевого приближения" хотелось бы услышать коментарии и советы форумчан, после чего и написать спецификацию.
То что мои изначальные посты чисто декларативные и без конкретики - это так. Зато теперь понятно что кому-то это все надо.

[denisxor]

Ваши мысли по поводу автоматизации мне близки Но я вижу второй этап несколько иначе...
Для того чтобы применить шаблон для преобразования карт от разных "Векторизаторов" к общему виду нужно либо "знать" ньюансы каждой из карт (каким типом какие объекты метит Векторизатор) либо договориться об общих правилах типизации и расположения объектов (о чем уже написано в этой ветке). А если мы собираемся выработать общие правила, то почему бы их сразу не выбрать такими чтобы никакого преобразования в дальнейшем не потребовалось.
То что вы предлагаете - это общий подход для большого картографического проекта у которого на выходе будут разные продукты сделанные на основе общей картоосновы. У нас все проще - карта для Garmin'a.

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

[denisxor]

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

А то что мои первые поситы делкаларативные и демагогические так это - сущая правда. До полноценной спецификации еще далеко (читайте посты выше в этом треде).

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

[denisxor]

То что Вы говорите - это все правильно. Общий принцип разделения данных, их отображения и алгоритмов обработки (Model/View/Controller) используется много где, но всеж не везде.
Как Вы правильно заметили вопрос этот технологический - вот это и пугает
Идея-то хорошая, но сколько ресурсов потребует ее реализация!
Мне кажется эффективней порождать куски карт в польском формате следуя общим правилам, (которых пока нет, но сосавить которые проще чем разработать, то что Вы предложили).

Есть ли у Вас конкретное предложение как отделить модель данных от отображения (польского формата) в нашем случае? Да так что-бы не перевооружать и не переобучать участников проекта (а большинство сидит в GPSMapEdit да R2V).

[SergeyV]

Осуществить постобработку достаточно просто, хотя и требует дополнительных небольших усилий. Я, например, для себя создал на Visual Basic'е программу, которая в БД ACCESS складывает информацию из файлов польского формата, а потом преобразует по заданному шаблону и выводит в файл в польском формате. Оказалось актуально, например, для того, чтобы из карт Евразии сделать что-то удобное для использования (правда, и ручной работы много оказалось).
А если задачу векторизации растра сейчас решить лишь частично, в соответствии со своими представлениями о насущности на сегодняшний день, то через пару лет придется все делать заново, и не факт, что обойдется небольшими правками. Нет ничего хуже чем править чужие готовые карты, зачастую проще создать свою. По этой причине я бы и Аэроскановскую топоснову отверг.
Вообще мы сейчас стали обсуждать какие-то рабочие вопросы. Я бы предложил сначала замутить проект, и там уже выработать окончательный подход
Сергей

[Olexa]

Хм, действительно, если люди уже работают в GPSMapEdit'е, то тратить время на переучивание и освоение чего-то другого не логично, логично потратить его на векторизацию. Привязка к классификатору ВТУ ГШ, опять-таки, спорна, поскольку, например, мы не собираемся вносить в карту длину пролётов и материал мостов, и скорости течений, хотя классификатор ВТУ ГШ соответствующий набор атрибутов имеет, и на используемых в качестве основы картах эти данны есть. Конечно, какие-то семантические данные, которые важны, но не находят достаточно детального отображения в польском формате, можно выносить в метки объектов, но без фанатизма. Тем более, что некоторые данные и не векторизуются-то особо (так, нет границ между зонами разного состава леса ≈ ель, дуб, бук и т. д.).

Так что, видимо, это я загрул насчёт классификатора ВТУ ГШ и не-GPSMapEdit'а.

[Olexa]

Если конечная цель ≈ карта для Garmin'а, то не поддерживаемую информацию никто векторизировать и не будет (и так ведь сплошной альтруизм), а поэтому и за пределы средств работы с Garmin'овскими картами выходить нет смысла, тем более, что это будет требовать дополнительных затрат. Да, кто-то будет векторизовать в Global Mapper'е, и будет прав, качество его части будет выше, но если кто-то не владеет Global Mapper'ом, и ему тяжело его освоить, то и за векторизацию в GPSMapEdit'е ему будет огромное спасибо.

[Olexa]

Всецело согласен, нарушать заложенную Garmin'ом семантику никак нельзя. Можно только пытаться изголяться в её пределах, даже если они в чём-то Прокрустовы.