Re: TCL mapscript
On 2007.03.04 at 23:10:28 +0300, Pechnikov Alexey wrote:
> > Биндинг для libproj я бы, например, сделал следующим образом:
> >
> > Она же вызывается как CmdDeleteProc.
>
> Спасибо, есть теперь над чем думать, буду смотреть в указанном направлении.
>
> Еще вопрос есть, что можно выкинуть, а что нужно оставить. Например, есть
Общий принцип такой - когда дизайнится абстракция, стоит подумать о
возможности последующего расширения. Но реализовывать сначала - только
то, чем будешь реально пользоваться. И иметь в виду, что возможно, те
варианты использования абстракции, которыми ты не пользуешься, потом
могут потребовать немного поменять саму абстракцию.
> возможность проецировать вектора через proj, а можно пользоваться функциями
> postgis.
На мой взгляд, здесь следует предусмотреть у исходного вектора свойство
"проекция". И если он уже в нужной проекции, гнать в изображение как
есть, а если нет - через libproj. На уровне примитива отрисовки.
На уровне объекта "векторный слой", который знает о том где он хранит
данные, тогда можно будет решать, то ли преобразовывать вектора при
отрисовке, то-ли просить у хранилища сразу в нужной проекции.
> Последний вариант работает только если карты в postgresql хранятся,
> зато возможности на порядок шире (например, можно найти объекты на одной
> карте, которые поподают в выюранную область на другой, причем карты в разных
> проекциях). На практике для города-миллионника карта с точностью до дома
> имеет право жить только в базе, иначе слишком накладно с точки зрения
> производительности (если сравнивать обработку из базе и из шейпфайлов).
шейпфайл arcview-шного формата не единственный и не лучший способ
хранения векторной информации. Но вообще фильтрацию объектов по заданной
области следует спихнуть на уровень драйвера хранилища. Там это можно
фильтровать специфичным для хранилища способом.
Мне попадались, например, такие векторные форматы, где в заголовке
каждой полилинии указывался bounding box, что позволяло при больших
увеличениях крайне эффективно пропускать те линии, которые оказываются
за пределами окна.
Вообще, одним из самых эффективных способов хранения информации о
сложных территориях является, как ни странно, растр с размером ячейки,
сопоставимым с разрешением сканирования исходной бумажной карты. Он
позволяет прямой доступ по координатам. Многие вещи, с которыми
разработчики преимущественно векторных ГИС бьются годами, сочиняют
нетривиальные алгоритмы, требующие часов машинного времени, в растре
делаются тривиально. Конечно, сетевые алгоритмы на растре могут
оказаться тормозными и требовать специальной предобработки, но всё что
имеет площадную природу...
> Разумно ли ограничиться работой только с базой или стоит подумать и о
> файловом хранении? То есть стоит думать о минимально необходимом или о полном
> наборе возможностей?
Стоит думать об обоих. О минимально необходимом с точки зрения
реализовать здесь и сейчас, о полном - с точки зрения, чтобы его можно
было потом дописать, и при этом
а) не порушить уже написанных для минимального скриптов
б) позволить этим скриптам по возможности прозрачно использовать вновь
появляющиеся возможности.
>
> Вот с такими функциями в дебиане mapserver конфигурится:
>
> ./configure --prefix=/usr --enable-debug --without-tiff --without-pdf --with-gd=/usr --with-freetype=/usr
> \
> --with-zlib=/usr --with-png=/usr --with-xpm=/usr --with-jpeg=/usr --with-gdal --with-ogr --with-proj --with-eppl
> \
> --with-postgis --with-wcs --with-wms --with-wmsclient --with-wfs --with-wfsclient --with-threads --with-geos
>
> На практике требуется намного меньше, хотелось бы представлять, до какого
> момента более скромная версия будет интересна сообществу, а после какого -
> только мне лично.
>
>
>
>
Reply to: