Сделал "вьюер" для осма

MapCSS. И если вы не понимаете, что это и зачем оно надо, значит, вы мало возились с мапником :slight_smile:

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

Отвечу скриншотом:

Про ошибки проектирования - внимательно слушаю.

Точнее будет сказать СОВСЕМ не имел дела.
О MapCSS впервые услышал в данной теме. Насколько я понял, это таблица стилей, заточенная под картографию.
Возможно, я ошибаюсь, но мне это представляется “рюшечками”.
Хотя, с другой стороны - каждый волен в свободное от работы время заниматься тем, чем лично ему хочется. А с третьей (стороны) - в любом случае хорошо, что одновременно с OSM развиваются и смеждый области.
Но мне все равно непонятно, какое это имеет отношение к osm?

А можно без жаргона?
Я, например, совершенно не представляю, что такое “текущий меркуриал”. Дело в том, что первое слово в этом словосочетании имеет несколько значений, а второе, насколько я знаю, в русском языке отсутствует (либо является именем собственным, но тогда бы оно писалось с прописной буквы). Могу лишь предположить что оно имеет отношение либо к ртути, либо к торговле (и совсем маловероятно - к одной из планет Солнечной системы).
Что же касается обсуждаемого проекта, мне кажется, что фраза “делаем векторые “тайлы”. кладутся в data. настроена на москву с окресностями (пару минут)” однозначно свидетельствует, что строится не изображение на экране, а какие-то тайлы, которые потом куда-то складываются.

Красиво, но непонятно.
Хотелось бы узнать, каков объем исходного osm файла, для которого построено это изображение, а также - сколько времиени ушло на каждый из этапов.

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

andriano, еще разок.

Чего вы хотите? :slight_smile:

А здесь что, пишут софт на заказ?

Человеку свойственно ошибаться.
И я здесь не исключение.
Поэтому когда вижу нечто, чего не могу понять/объяснить, у меня всегда возникает вопрос: кто именно ошибается?
А т.к. я веду потихонечку свой проект, и векторные геоданные берутся именно с osm, то меня интересует все, что делается подобное кем-то еще.
Именно на уровне идей.
Так что если Вы хотите услышать цель, то она - обмен опытом.

И да, вам еще перед этим постом сообщили, что там нет предварительной генерации тайлов.

Там нет предварительной генерации “растровых” тайлов (мозаики). Есть нарезка карты на куски (те же тайлы) для более быстрой отрисовки. Размер исходного .osm - 340Мб (Московская область). Тайлы на один зумлевел, без генерализации - занимают 200Мб. Это не конечный формат, а простой текстовый формат для отладки. Если делать оптимизированый бинарный формат, думаю, будет раз в 8-10 меньше.
И да, здесь пишут софт на заказ - в том смысле, что прислушиваются к дельным замечаниям.

Спасибо.
Что Московская область 340 Мб, а Россия 3.5 Гб, я в курсе. Сейчас как раз их и кручу. В основном - вторую.
Есть несколько вопросов:

  1. Сколько примерно времени занимает каждый из этапов подготовки данных и отрисовки для МО и РФ соответственно (у меня этапов больше - в сумме несколько минут для РФ - с учетом того, что данные полностью не помещаются в ОП и при обработке они неоднократно переписываются с места на место).
  2. По какому признаку происходит “нарезка” - именно по тайловому принципу (т.е. резать "по живому) или Объекты просто распихиваются по контейнерам (я у себя предпочел этот вариант).
  3. Какой примерно размер одного “тайла” в каких-либо вменяемых единицах (у меня от нескольких десятков до пары сотен объектов, где объект - это узел или полилиния).

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

http://code.google.com/p/kothic/source/checkout - ccылку я уже кидал.
http://ru.wikipedia.org/wiki/Mercurial - собственно, меркуриал.
Не представляю, что в этой фразе нельзя было понять при наличии желания.

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

108 017 318 символов, на конвертацию c генерализацией osm->тайлы ушло 40 минут, на рендер скриншота около полутора секунд. Оптимизацией еще никто не занимался, ибо рано.

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

Котяра, сорри за офф, а MapCSS к мапнику применим? А то я неделю курю мануал к мапнику - о очень мне от него плохо :frowning: Тут все даже для такого ламера как я выглядить чуть понятнее.

Как все сложно…
Нет, я вполне понимаю, что алгоритм, который рисует красиво, управляемо, да еще и правильно - сам по себе нетривиальная инженерная задача. И, вероятно, не только инженерная.

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

Спасибо.
Самое интересное - это, конечно, те самые 40 минут.
Тот вариант, что ку меня в настоящее время рабртает, основан на MP из osm2mp. Около 300 Мбайт МР (РФ + Украина) переводятся в пригодный для отображения формат около 5 минут.
Но результат меня не совсем удовлетворяет, т.к. отрисовка кадра не всегда укладывается в 30 мс. Среднее время - 11 мс, но, увы, бывают существенные откорнения в большую сторону, поэтому думаю над переделкой алгоритма.
Но и кроме того, lesha убедил меня в том, что целесообразно пользоваться не МР, а оригинальный osm, так что сейчас пока переключился на анализ исходного osm с целью понять, в каком виде данные мне целесообразно из него добывать.

Это невозможно. Никак. XML формат для этого принципиально не подходит. Несмотря даже на самописный парсер, который работает раз в 100 быстрее майкрософтовского.

Пока мне тут рассказывают про невозможность, покажу новую картинку:

А почему у домов стены прозрачные?

И все-таки, неужели кто-то оспаривает непригодность формата osm для реалтаймового рендеринга?

О, круто, а высота домиков у всех одна или просто так совпало? (Ищу чем бы смотреть осм в изометрии по Екатеринбургу).

Котяра, не забудь про заборы! Их тоже можно красиво рисовать в изометрии :slight_smile:

А лесопосадки как будут отображаться? Мне вообще кажется, что нужно вьювер делать на базе какого-нибудь открытого 3D-движка. :slight_smile:

Потому что так записано в стиле.

Повторюсь: как будет записано в стиле. пока что для отладки просто - залиты зелёным :slight_smile:

Я бы не сказал, что осмовское 2.5D хорошо ляжет в 3D. Так что в этом году я этим точно не буду заниматься :slight_smile:

Высота задаётся в пикселях в стиле. Но в спеке MapCSS есть чудесная штука - eval(), которой можно сказать, что для получения значения надо тег “building:levels” умножить на три :slight_smile:
(пока не реализовано :wink:

Не применим, к сожалению. Иначе зачем бы я котика пилил? :wink:

Я давно жду конвертер ОСМа в формат карт какой-нить популярной игры типа GTA… - это будет хит. 8))

http://osm.kyblsoft.cz/3dmapa/?zoom=17&lat=75.75078&lon=14.31372&layers=B

Парки с деревьями, отражающимися в воде!

Офигеть! о_О Не хватает текстур для воды и травы)

Почесался и сделал надписи вдоль линий.