spacer

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

это не единичный случай, просто он сейчас на виду. подобный случай с точками "питьевая вода"/"родники, колодцы"... и т.д. я константина прекрасно понимаю, нет узаконенного тайпсета - нет движухи... есть тайпсет гармин, к нему дополнением есть навител... константин сделал тип "универсальный", в котором появилась поддержка этажности ситигида (хоть какой прогресс)! появилась (заявлена) официальная поддержка в гме полосности, хотя и не в полной мере! польский вообще в этом плане универсален, в самом тексте исходника можно "лепить" все, что хочется... проблемы возникают при редактиров

kzvs, спасибо! если DuNkan не понимает то, что я пишу по этому поводу, то хоть это воспримет (все же разными словами написано про одно и тоже)! DuNkan, 1. не вариант (есть стандартные типы, которые НЕЛЬЗЯ менять). 2. kzvs написал тоже самое, что и я на предыдущих страницах, но другими словами! в теме минимум три "картографа-любителя" говорят, что нельзя менять существующие типы в "польском", но вы упорно продолжаете с этим спорить! DuNkan, в сборе и каталогизировании "узких" мест в конвертации исходников в карты для систигида и в работе самой программе помогу. собственно именно з

все именно так! для пишущих общее пожелание к мит по учету замечаний "любителей" - запишите это "слово в слово"! если мы говорим об унификации хранения исходных данных (коей для нас любителей является устоявшийся текстовый "польский"), то это вообще не вариант! некоторые авторы так и делают... обозначая все пожелания пользователей словом "записано" ;-) ну и в заключение на сегодня... поиск для любительских многофайловых карт (без обзорки/атласа) не работает! маршрутизация по обзорке "россия" за уралом на восток кривая (направленные замечания не исправлены уже по

вот. а то, что эти типы (конкретно post_office = 0x2f05 и 0x640f) обозначаются так еще со времен гармина и должны быть неизменны никто не задумывался при нововведениях для ситигида ;-) но опять же повторюсь... это не повод при его стандартизации (митовского тайпсета) коверкать уже устоявшиеся существующие типы точек.

сейчас посмотрел как это выгружается из осм... там post_office = 0x2f05 (если ничего в скрипте выгрузки не поменяли). это значит, что все "почтовые отделения" стали "салонами сотовой"? ;-) надо у Пирса поинтересоваться, как это сейчас выглядит!

кстати, в список нереализованного добавьте распознавание при конвертации полигонов 0x68 (улица крупная), 0x69 (городская магистраль), 0x65 (площадь), 0x6b (дорога), 0x27 (взлетно-посадочная полоса). сейчас конструктор на эти типы ругается.

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

с учетом type-garmin-ru.dat и type-navitel-ru.dat, т.к. эти два файла формируют список poi в gme для TypeSet=NG (универсальный), который используется для хранения данных в польском для их отображения(конвертации) для ситигида.

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

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

уже писалось выше.... иконки мостов верните, сейчас остались только надписи.

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

олег, комментарии видны только правщикам исходника, а "красные треугольники" видны пользователям. у нас таксисты выдают актуальную инфу по этим точкам, которую мы оперативно вносим в исходник (обратная связь!).

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

в качестве справочника давно более интересен 2гис, скоро он будет интереснее и в плане внутригородской навигации (с пробочным сервисом). конкуренты не дремлют! ;-)

про работу Find_Duplicated_Address.d... очень замечательно, что появился этот скрипт, огромное спасибо! предложение... хотелось бы реализацию работы скрипта видеть в виде "дерева" в таком виде: [-] информация о дубле: [-] первый дубль: [+] информация о первом дубле [-] второй дубль: [+] информация о втором дубле [+] n-ый дубль.

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

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

картаоснова какая 2014q1?

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

олег, я закомментированные строки в полишконвертере нашел сразу (еще до твоего сообщения). мне было непонятно, почему часть колонок на картах есть, а чести нет. полез в исходник смотреть тип точек, которые в карты попадали. все оказалось в разных типах пои, продублировал строки для типа 5000 заменив тип на 6414, все появилось.

я не выдумываю. добавил в полишковертер описание типа 6414 (скопировав с типа 5000): poi_6414 //@ // Drinking Water {//18138 WELLLL { POICAT="water" priort=906 LABELS="{{Label}}" POITYP=201 NUMBER="{{HouseNumber}}" STRNAM="{{StreetDesc}}" DSTNAM="{{DistrictName}}" TWNNAM="{{CityName}}" TERNAM="{{CountryName}}" REGNAM="{{RegionName}}" PHONES="{{Phone}}" FAXNUM="{{Fax}}" WEBPGE="{{WebPage}}" EMAILS="{{Email}}" OPTIME="{{OpeningHours}}" FULNAM="{{FullName}}" INFORM="{{Text}}" } $texts { POICAT="water" priort=909 txtval="{{Label}}" rgbnam="#00BFFF" fnthei=7 fntstl={ 2,5 } justh=3 jus

файл есть обязательно. у объектов, которые в него попадают тип = Питьевая вода (0x5000, точка), а не тип = Питьевая вода, родник, колодец (0x6414, точка)

у этих точек есть "Label=Питьевая вода", о чем я и писал в первом сообщении данной ветки.