Конвертация OSM в Navitel

Семён Семёнов · 2013-12-20 16:18:37

Прокладываю маршрут НН7.5 :
addr:city=Краснодар
addr:country=RU
addr:housenumber=1
addr:street=Привокзальная площадь
building:levels=2
building=yes
name:en=Krasnodar 1
name=Краснодар-1
start_date=1952

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

П. С. Kostik, спасибо, просмотрел файлы, действительно нет start_date, попробую на симуляторе проверить.

Last edited by Семён Семёнов (2013-12-20 17:58:53)

Kostik · 2013-12-20 16:47:40

Семён Семёнов wrote:

start_date

Данный тег не попадает при конвертации в MP и далее в nm2. Это можно посмотреть в конфиге к osm2mp или в готовом mp.

Konsta · 2013-12-20 19:52:33

В проходе от 19.12.2013 04:40 файлик Russia-MOS-routing.nm2 потерялся...

Kostik · 2013-12-21 09:39:07

Konsta wrote:

Russia-MOS-routing.nm2 потерялся

http://forum.openstreetmap.org/viewtopi … 74#p169074

Sergey Astakhov · 2013-12-24 21:48:15

http://www.openstreetmap.org/relation/3342134

Может не стоит такие данные хранить в OSM? Чем не устраивает использование poly-файлов, как у прочих конвертеров?

Kostik · 2013-12-25 06:38:09

Sergey Astakhov wrote:

Может не стоит такие данные хранить в OSM?

А чем не устраивает или мешает? И чем это кардинально отличается от комментированной линии без тегов или полигона?

Last edited by Kostik (2013-12-25 06:43:06)

freeExec · 2013-12-25 06:41:52

Sergey Astakhov wrote:

Может не стоит такие данные хранить в OSM? Чем не устраивает использование poly-файлов, как у прочих конвертеров?

А ты растяни его на всё Россию

Kostik · 2013-12-25 06:44:42

freeExec Это уже хулиганством попахивает!

Sergey Astakhov · 2013-12-25 07:08:35

Kostik wrote:

А чем не устраивает

Хранить настройки конвертации для конкретной программы в общей геобазе объектов? Ну хотя бы тем, что это противоречит важному принципу проверяемости.
Ну и мы тут как бы карту рисуем, поэтому линии, специфичные для какого-то сервиса/программы, не имеющие отношения к объективно существующим картографическим сущностям, такие как полигоны обрезки или покрытия снимков, вносить сюда не стоит. Сделайте poly-файлы, выложите их на тот же github - и вам будет удобно, и случайно никто их не поломает, что регулярно происходит с теми же границами в OSM при редактировании.

Last edited by Sergey Astakhov (2013-12-25 07:22:50)

chnav · 2013-12-25 07:19:13

getbound.pl поддерживает алиасы, состоящие из нескольких отношений. Правится локальный файл под любые нужды.
http://forum.openstreetmap.org/viewtopi … 73#p376173

Last edited by chnav (2013-12-25 07:19:29)

Kostik · 2013-12-25 08:36:27

Sergey Astakhov wrote:

оэтому линии, специфичные для какого-то сервиса/программы, не имеющие отношения к объективно существующим картографическим сущностям, такие как полигоны обрезки или покрытия снимков, вносить сюда не стоит.

Какие линии? Акститесь! Мультиполигон это отношение! И в данном случае ничего не добавлено ни точек, ни линий!

Sergey Astakhov wrote:

Сделайте poly-файлы

OSM это не конечный продукт замороженный во времени, он имеет тенденции меняться, как могут меняются и границы. poly-файлы и так хранятся локально, актуализируются перед каждой конвертацией.

Sergey Astakhov wrote:

и случайно никто их не поломает

Поломают, починим! Я их регулярно проверяю.

chnav wrote:

getbound.pl поддерживает алиасы, состоящие из нескольких отношений.

Это ещё более сложный в проверке и не надёжный вариант. Вместо того чтобы проверить один мультиполигон надо помнить и проверять все.

chnav · 2013-12-25 08:55:17

Kostik wrote:

Это ещё более сложный в проверке и не надёжный вариант. Вместо того чтобы проверить один мультиполигон надо помнить и проверять все.

Информация про алиасы лишней не будет В вашем случае (имею в виду полигон для Севера) отдельный relation, возможно, оправдан. А в более сложных случаях лучше обойтись алиасами. Например Москва или Питер, где мультиполигон на мультиполигоне и мультиполигоном погоняет.
Для проверки достаточно иногда открывать poly в JOSM, все косяки видны сразу.

Sergey Astakhov · 2013-12-25 08:59:38

Kostik wrote:

Sergey Astakhov wrote:
оэтому линии, специфичные для какого-то сервиса/программы, не имеющие отношения к объективно существующим картографическим сущностям, такие как полигоны обрезки или покрытия снимков, вносить сюда не стоит.
Какие линии? Акститесь! Мультиполигон это отношение! И в данном случае ничего не добавлено ни точек, ни линий!

Отношения в модели OSM - это такой же равноправный объект, как линии и точки.

Kostik · 2013-12-25 09:04:33

И чем же вам помешало данное отношение? Или может оно нарушает какие то правила? Я могу привести примеры не менее бесмысленных на первый взгляд, но надо ли? Кто их использует и так знает зачем они ему нужны.

chnav
Нет ни времени, ни желания возиться с алиасами. И только из-за недовольства Сергея переделывать то что работает и никому не мешает, не вижу смысла.

PS: Я сам не пользуюсь картами для Навитела и считаю их ересью и архаизмом, собирать под него карты большой гиморой. Но кто то пользуется поэтому данный проект существует.

Last edited by Kostik (2013-12-25 09:18:10)

rashaurl · 2013-12-27 10:59:38

уважаемые Fortress и Kostik, карты после конвертации Казахстана, а в частности Уральска, занимают не так много места, поэтому хотел попросить немного увеличить детализацию, что прямые углы были прямыми углами у зданий.

Kostik · 2013-12-27 14:37:33

rashaurl wrote:

что прямые углы были прямыми углами у зданий

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

Kostik · 2013-12-27 20:04:23

rashaurl Выложил тестовую сборку Казахстана с 26битной точностью.

rashaurl · 2013-12-28 15:57:19

спасибо, так значительно красивее))

xscvxc · 2014-01-04 12:20:50

Use of uninitialized value $xmin in numeric lt (<) at C:/Perl64/site/lib/Math/Po
lygon/Tree.pm line 238.
Use of uninitialized value $xmax in numeric gt (>) at C:/Perl64/site/lib/Math/Po
lygon/Tree.pm line 238.
Внезапно посыпались ошибки, никто не знает, что ему надо?(Tree установлен.)

Last edited by xscvxc (2014-01-05 09:38:52)

Kuprienko_Viktor · 2014-01-07 06:00:17

Поиск в Мурманской области работает только до уровня населенного пункта. Что-то сломалось?
(навител 5.03, Russia-MUR за 3.01.14)

Kostik · 2014-01-07 09:23:53

Kuprienko_Viktor wrote:

Что-то сломалось?

В Кандалакше ищет, надо проверять границы мультиполигонов и теги тех НП где не ищет.
PS: Тут недавно некоторые занимались валидацией под валидатор, возможно что то поломали с поиском. В первом посте этой темы есть условия которые необходимы для нормально работающего поиска.
PPS: iWowik при разделении границ и мультиполигона неправильно задаёт теги, вот например мультиполигон Мурманска, а вот точка центра. Сразу бросается что у мультиполигона не проставлены теги addr:country, addr:district и addr:region которые есть на точке.
В Апатитах снёс addr:district:

дальше пока не смотрел.

Last edited by Kostik (2014-01-07 09:57:24)

chnav · 2014-01-08 17:00:49

Коллеги, если будете Казахстан конвертировать пожалуйста включите два новых рилейшена, без них в карте будут дырки. Спасибо !
http://forum.openstreetmap.org/viewtopi … 72#p389772

DenVilKam · 2014-01-09 10:33:50

Извиняюсь. Я так понимаю здесь конвертят карту в Навител сами?
По неопытности возник вопрос.. Сейчас я беру карты для Навител с сайта openstreetmaps.ru.
К сожалению в отконвертированные карты не попадают некоторые объекты, например Частная фирма (Office=company).

dimuzz · 2014-01-09 13:43:27

DenVilKam wrote:

К сожалению в отконвертированные карты не попадают некоторые объекты, например Частная фирма (Office=company).

Дело в том, что сборка заточена скорее под автонавигацию, чем под полный справочник предприятий.
Раньше эти объекты даже включались, но из-за невозможности точно сопоставить тегам типы POI были исключены.

DenVilKam · 2014-01-10 04:04:29

А может можно как-то сопоставить такие теги с каким-либо общим тегом? А то прилично объектов теряется и в Навител и в Гармин картах. Мог бы оказать содействие в силу своих способностей.

Announcement

#5901 2013-12-20 16:18:37

Re: Конвертация OSM в Navitel

#5902 2013-12-20 16:47:40

Re: Конвертация OSM в Navitel

#5903 2013-12-20 19:52:33

Re: Конвертация OSM в Navitel

#5904 2013-12-21 09:39:07

Re: Конвертация OSM в Navitel

#5905 2013-12-24 21:48:15

Re: Конвертация OSM в Navitel

#5906 2013-12-25 06:38:09

Re: Конвертация OSM в Navitel

#5907 2013-12-25 06:41:52

Re: Конвертация OSM в Navitel

#5908 2013-12-25 06:44:42

Re: Конвертация OSM в Navitel

#5909 2013-12-25 07:08:35

Re: Конвертация OSM в Navitel

#5910 2013-12-25 07:19:13

Re: Конвертация OSM в Navitel

#5911 2013-12-25 08:36:27

Re: Конвертация OSM в Navitel

#5912 2013-12-25 08:55:17

Re: Конвертация OSM в Navitel

#5913 2013-12-25 08:59:38

Re: Конвертация OSM в Navitel

#5914 2013-12-25 09:04:33

Re: Конвертация OSM в Navitel

#5915 2013-12-27 10:59:38

Re: Конвертация OSM в Navitel

#5916 2013-12-27 14:37:33

Re: Конвертация OSM в Navitel

#5917 2013-12-27 20:04:23

Re: Конвертация OSM в Navitel

#5918 2013-12-28 15:57:19

Re: Конвертация OSM в Navitel

#5919 2014-01-04 12:20:50

Re: Конвертация OSM в Navitel

#5920 2014-01-07 06:00:17

Re: Конвертация OSM в Navitel

#5921 2014-01-07 09:23:53

Re: Конвертация OSM в Navitel

#5922 2014-01-08 17:00:49

Re: Конвертация OSM в Navitel

#5923 2014-01-09 10:33:50

Re: Конвертация OSM в Navitel

#5924 2014-01-09 13:43:27

Re: Конвертация OSM в Navitel

#5925 2014-01-10 04:04:29

Re: Конвертация OSM в Navitel

Board footer