GIS-Lab - Вклад [ru]

Примеры использования ogr2ogr

2021-06-23T14:26:54Z

Boris:

{{Статья|Опубликована|ogr2ogr-examples}}
{{Аннотация|Перечь примеров для справки}}

С библиотекой gdal поставляется утилита ogr2ogr, предназначнная для конвертации векторных данных. В данной статье приводятся примеры использования этой утилиты.

[http://www.gdal.org/index.html GDAL/OGR] - библиотека для работы с географическими форматами данных. GDAL представляет собой набор утилит для обработки растровых данных, в то время, как OGR предназначена для работы с векторными форматами. В статье рассматриваются некоторые практические примеры применения одной из утилит этой библиотеки: программы ogr2ogr. Примеры использования утилит для растровых данных приводятся в [http://gis-lab.info/qa/gdal-examples.html другой статье].

== Общие сведения ==

Программа ogr2ogr предназначена для конвертации векторных данных из одного формата в другой. Поддерживаемые форматы и используемые ключи можно узнать просто набрав в коммандной строке

<pre>ogr2ogr</pre>

В результате будет получена справка по использованию этой программы:

<pre>ogr2ogr [--help-general] [-skipfailures] [-append] [-update] [-gt n]
[-select field_list] [-where restricted_where]
[-sql ]
[-spat xmin ymin xmax ymax] [-preserve_fid] [-fid FID]
[-a_srs srs_def] [-t_srs srs_def] [-s_srs srs_def]
[-f format_name] [-overwrite] [[-dsco NAME=VALUE] ...]
[-segmentize max_dist]
dst_datasource_name src_datasource_name
[-lco NAME=VALUE] [-nln name] [-nlt type] [layer [layer ...]]</pre>

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

*ESRI Shapefile
*MapInfo File
*TIGER
*S57
*DGN
*Memory
*BNA
*CSV
*GML
*GPX
*KML
*GeoJSON
*Interlis 1
*Interlis 2
*GMT
*SQLite
*ODBC
*PostgreSQL
*MySQL
*Geoconcept

==Специфика работы с кириллицей==

Чтобы ogr2ogr корректно работал с файлами в названии которых есть кириллица, необходимо, перед выполнением команд установить переменную среды:
<pre>SET GDAL_FILENAME_IS_UTF8=OFF</pre>

Если исходные данные в кодировке UTF-8, то необходимо явным образом указывать, что выходные данные также будут в UTF-8, с помощью опции <code>-lco ENCODING=UTF-8</code>, например:
<pre>ogr2ogr -lco ENCODING=UTF-8 output.shp input.vrt</pre>

==Использование конфигурационных опций==
Для ряда форматов через конфигурационные опции можно задать дополнительные настройки. Так, например, для формата SXF можно указать местоположение классификатора (файл RSC). Конфигурационные опции можно задавать через переменные окружения:

<pre>export SXF_RSC_FILENAME=map50.rsc</pre>

или в командной строке утилит (использование RSC из файла с другим именем):

<pre>ogrinfo --config SXF_RSC_FILENAME map50.rsc N-36-045.sxf</pre>

несколько опций задаются каждая со своим ключём (использование RSC из файла с другим именем и полные названия слоёв):

<pre>ogrinfo --config SXF_RSC_FILENAME map50.rsc --config SXF_LAYER_FULLNAME TRUE N-36-045.sxf</pre>

==Конвертация==

В примерах ниже будет использоваться shape-файл [http://gis-lab.info/data/topogrid/topo2km-rus.7z topo2km-rus.shp] со следующими характеристиками:

<pre>Layer name: topo2km-rus
Geometry: Polygon
Feature Count: 10368
Extent: (-180.000000, 36.000000) - (180.000000, 88.000000)
Layer SRS WKT:
GEOGCS["GCS_Pulkovo_1942",
DATUM["Pulkovo_1942",
SPHEROID["Krasovsky_1940",6378245.0,298.3]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]]
HEMISPHERE: String (1.0)
INDEXROMAN: String (21.0)
INDEXNUM: String (12.0)
UNIQUE: String (25.0)
ZONE: String (1.0)
I10KM: Integer (4.0)
I10KMZSTR: String (2.0)
INDEXFULL: String (50.0)
I2KM: Integer (4.0)
I2KMZSTR: String (50.0)</pre>

Конвертировать ESRI Shapefile в формат MapInfo TAB можно следующим образом:

<pre>ogr2ogr -f "MapInfo File" topo2km-rus.tab topo2km-rus.shp</pre>

В результате в текущем каталоге появится 4 файла topo2km-rus.* --- результат конвертации.

Теперь конвертируем только некоторые объекты из файла topo2km-rus (в поле ZONE которых содержится строка "s"):

<pre>ogr2ogr -f "MapInfo File" -where "ZONE=s" topo2km-rus.tab topo2km-rus.shp</pre>

Аналогично можно воспользоваться параметрами:

-select для выбора определенных полей таблицы атрибутов. Например скопировать набор данных убрав все поля кроме name:

<pre>ogr2ogr -f GeoJSON -select name output.geojson input.geojson</pre>

#-spat для выбора объектов, лежащих в определенных пространственных границах

Конвертация из CSV в shape-файл и обратно подробно рассмотрена в [http://gis-lab.info/qa/csv2shp.html отдельной статье].

==Работа с комплексными наборами данных==
Существуют форматы позволяющие хранить несколько слоёв с разными геометриями. Например SXF. Для экстракции всех слоёв в формат ESRI Shape в качестве цели указывается папка, а не имя файла:
<pre>ogr2ogr output_dir input.sxf</pre>

Адресация конкретного слоя в таких наборах данных из нескольких слоёв адресация каждого слоя в этом случае осуществляется через пробел, например:
<pre>ogr2ogr output_dir input.sxf layer_name</pre>

==Конвертация из форматов не ограниченных по типу геометрии==

Для форматов, которые позволяют хранить в одном слое сразу несколько типов геометрий нужен нестандартный подход, так, чтобы конвертировать MIF/MID в формат ESRI Shape нужно указать тип геометрии, например:

<pre>ogr2ogr -skipfailures input_POINT.shp input.mif -nlt "POINT"</pre>

или, чтобы получить все типы геометрий, можно использовать цикл (Windows):

<pre>for %n in (POINT POLYGON) do ogr2ogr -skipfailures output_%n.shp input.mif -nlt "%n"</pre>

Этот подход может не подойти, так как при конвертации может происходить конвертация типов геометрии, что приведет к появлению копии данных с другой геометрией. Например, такая команда:

<pre>ogr2ogr -skipfailures output_LINESTRING.shp input.mif -nlt "LINESTRING"</pre>
Приведет к созданию линейного shape-файла, несмотря на то, что в исходном файле вообще может не быть линий, а только полигоны. Следует отметить, что преобразования между одинаковыми типами с составными объектами, наоборот, не произойдет. Т.е. MULTILINESTRING не переведется в LINESTRING, а MULTIPOLYGON в POLYGON.

В связи с этим, более правильным подходом будет явным образом указать тип данных через -sql запрос, например:

<pre>ogr2ogr -skipfailures output_LINESTRING.shp input.mif -nlt "LINESTRING" -sql "SELECT * FROM Input WHERE OGR_GEOMETRY='LINESTRING'"</pre>

Полностью обработать данные для всех файлов с определенным расширением и всех типов геометрии можно так (цикл для командного интерпретатора Windows):

<pre>for %i in (*.mif) do for %n in (POINT LINESTRING POLYGON MULTIPOLYGON MULTIPOINT MULTILINESTRING) do ogr2ogr -skipfailures %~ni_%n.shp %i -nlt "%n" -sql "SELECT * FROM '%~ni' WHERE OGR_GEOMETRY='%n'"</pre>

В этом случае если в исходнике нет линий, то они не будут сконвертированы из полигонов, будет создан пустой shape-файл.

== Использование OGR SQL ==
===Выборка===
Можно построить и более сложные условия для выборки данных с помощью [http://www.gdal.org/ogr_sql.html OGR SQL] и параметра "-sql".

Выбрать при конвертации только объекты из таблицы "topo2km-rus", поле ZONE которых содержит 'PERVOMAYSK'

<pre>ogr2ogr -f "MapInfo File" -sql "SELECT * FROM topo2km-rus WHERE ZONE='PERVOMAYSK'" topo2km-rus.tab topo2km-rus.shp</pre>

Выбрать отдельные поля в определённом порядке:

<pre>ogr2ogr -f "MapInfo File" topo2km-rus.tab topo2km-rus.shp -sql "SELECT I2KMZSTR, I2KM, INDEXNUM FROM topo2km-rus)"</pre>

Выбрать и переименовать "на лету" отдельные поля в таблице

<pre>ogr2ogr -f "MapInfo File" topo2km-rus.tab topo2km-rus.shp -sql "SELECT I2KMZSTR AS 'i2kmzstr', I2KM AS '2km', INDEXNUM FROM topo2km-rus"</pre>

Сменить тип поля "на лету" у выбранных полей (можно совмещать смену полей с их переименованием)

<pre>ogr2ogr -f "MapInfo File" topo2km-rus.tab topo2km-rus.shp -sql "SELECT CAST (I10KM AS CHARACTER(4)), CAST (I2KM AS FLOAT) FROM topo2km-rus)"</pre>

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

Значительно упростить команду можно использовав вместо ключа -sql ключ -where, его использование делает ненужным указание конструкции <code>SELECT * FROM 'filename' WHERE</code>. Пример:

<pre>ogr2ogr -skipfailures output_MULTIPOINT.shp input.MIF -nlt "MULTIPOINT" -where "OGR_GEOMETRY='MULTIPOINT'"</pre>

вместо:

<pre>ogr2ogr -skipfailures output_MULTIPOINT.shp input.MIF -nlt "MULTIPOINT" -sql "SELECT * FROM input WHERE OGR_GEOMETRY='MULTIPOINT'"</pre>

Обратите внимание:

* что в паре <fieldname>=<значение>, если значение - строка, то она должна браться в одинарные кавычки, как в примере выше, т.е.: -where "HIGHWAY = 'motorway'".

* после FROM требуется указать название таблицы и здесь может идти как название слоя (для ESRI Shape) так и, что-то иное для форматов с гибридными геометриями, например OGRGeoJSON (для GeoJSON).

При выборке можно производить проверку значений на предмет равенства или неравенства:

<pre>ogr2ogr -sql "SELECT * FROM %~ni WHERE field1 NOT IN (0,12,13,15,16,254,255) AND field2 != -1" output.shp input.shp</pre>

Используя диалект SQLITE можно производить выборку определенного количества случайных точек:

<pre>ogr2ogr -sql "SELECT * FROM input WHERE field1 NOT IN (0,12,13,15,16,254,255) AND field2 != -1 ORDER BY RANDOM() LIMIT 10000" -dialect SQLITE output.shp input.shp</pre>

=== Работа с полями и значениями ===
Добавить поле можно следующим образом (нового слоя не создаётся):
<pre>ogrinfo input.shp -sql "ALTER TABLE input ADD COLUMN newfield integer(3)"</pre>

Если нужно добавить значение в существующее поле, то нужна команда UPDATE, но она не поддерживается OGR SQL, поэтому нужно использовать диалект. Заполнить поле значениями можно вот так:
<pre>ogrinfo input.shp -dialect SQLite -sql "UPDATE input SET textfield = 'sometext'"</pre>

Драйвер SQLite должен быть скомпилирован с поддержкой [http://www.gdal.org/ogr_sql_sqlite.html диалекта SQLite SQL], иначе будет выводиться сообщение об ошибке: "ERROR 6: The SQLite driver needs to be compiled to support the SQLite SQL dialect".

Использование диалекта [https://gdal.org/user/sql_sqlite_dialect.html#sql-sqlite-dialect "SQLite"] делает возможным применение огромного набора функций и операций, реализованной в данной СУБД, включая пространственное расширение [http://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html "SpatiaLite"].
Например, операция по присвоению полю таблицы Mapinfo значения идентификатора UUID/GUID может быть легко реализована следующей командой:
<pre>ogrinfo -so myTab.TAB -dialect SQLite -sql "UPDATE myTab SET GLOBALID=CreateUUID()"</pre>

===Пространственные операции===

Используя ExecuteSQL можно выполнять и пространственные операции. Допустим есть два слоя - полигоны и точки и мы хотим посчитать количество точек в каждом полигоне.

Создаем файл vrt:
<pre><OGRVRTDataSource>
<OGRVRTLayer name="pol">
<SrcDataSource>pol.shp</SrcDataSource>
<SrcLayer>pol</SrcLayer>
</OGRVRTLayer>
<OGRVRTLayer name="pnt">
<SrcDataSource>pnt.shp</SrcDataSource>
<SrcLayer>pnt</SrcLayer>
</OGRVRTLayer>
</OGRVRTDataSource></pre>

И выполним запрос с привлечением функции ST_Intesects:

<pre>ogrinfo -sql "SELECT COUNT(*) FROM pol, pnt WHERE ST_Intersects(pol.geometry,pnt.geometry) GROUP BY pol.id" -dialect SQLITE input.vrt</pre>

==Работа с системами координат==
===Переназначение системы координат===
Если вам нужно просто перепрописать систему координат, без пересчета самого набора данных:

TODO

=== Перепроецирование ===

Для перевода данных из одной системы координат в другую могут использоваться следующие параметры:

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

Например, мы знаем, что файл topo2km-rus.shp содержит данные в географической системе координат Пулково 1942, но в комплекте с topo2km-rus.shp нет файла описания проекции (*.prj). Мы можем сгенерировать этот файл, воспользовавшись командой:

<pre>ogr2ogr -a_srs "EPSG:4284" -f "ESRI Shapefile" topo2km-rus2.shp topo2km-rus.shp</pre>

Команда:

<pre>ogr2ogr -s_srs "EPSG:4326" -t_srs "EPSG:900913" -f "ESRI Shapefile" topo2km-rus3.shp topo2km-rus2.shp</pre>

берет созданный на предыдущем этапе файл topo2km-rus2.shp и перепроецирует его в систему координат Google Mercator (epsg 900913), при этом опция -s_srs "epsg:4326" говорит о том, что при перепроецировании не нужно обращать внимания на исходную проекцию файла topo2km-rus2.shp, т.е. вести себя так, будто проекция источника - широта/долгота WGS84 (epsg 4326).

В приведенных примерах система координат указывалась на основе кодов epsg, но ее можно указывать и непосредственно в формате WKT или же передавать имя файла, в котором хранится ее описание. Например, если необходимо использовать описания систем координат, хранящихся в файлах input.prj и output.prj, то нужно использовать следующую конструкцию:

<pre>ogr2ogr -s_srs ESRI::Input.prj -t_srs ESRI::output.prj shapeout.shp shapein.shp</pre>

Перепроецировать данные с указанием набора параметров перехода из одной системы координат в другую можно следующим образом:

<pre>ogr2ogr -t_srs "+proj=latlong +ellps=krass +towgs84=23.92,-141.27,-80.9,0,0,0,0" shapeout.shp shapein.shp</pre>

== Обрезка ==

Можно обрезать данные по нужному охвату, углы задаются в формате мин X, мин Y, макс X, макс Y.

<pre>ogr2ogr -clipsrc 41.4 46.4 41.6 46.6 output.shp input.shp</pre>

Вместо координат можно обрезать и по сложной форме заданной другим shape-файлом:

<pre>ogr2ogr -clipsrc clipbound.shp output.shp input.shp</pre>

пакетно (Win):

<pre>for %n in (*.shp) do ogr2ogr -clipsrc clipbound.shp output_folder/%n %n</pre>

пакетно (Ubuntu):

<pre>for f in *.shp; do ogr2ogr -lco ENCODING=UTF-8 -clipsrc clipbound.shp output_folder/${f} ${f}; done</pre>

==Объединение==
Суть объединения по ogr'овски в том, что сначала создается копия первого источника данных, а потом к этой копии добавляются данные из второго, и т.д.

<pre>ogr2ogr result.shp input1.shp
ogr2ogr -update -append result.shp input2.shp -nln result</pre>

==Объединение по общему полю==
В OGR можно использовать операцию JOIN:

<pre>ogr2ogr -sql "select input.*, table.* from input LEFT JOIN 'table.csv'.table ON input.id = table.IDINT" output.shp input.shp</pre>

В примере выше используется input.shp в качестве shape-файла и table.csv - в качестве присоединяемой таблицы. Присоединяемая таблица должна иметь расширение CSV. Обе таблицы разумеется должны иметь общее поле по которому будет происходить объединение, в данном случае это: id - поле в input.shp и IDINT - поле в table.csv. Ключом может быть и целочисленное и текстовое поле.

Следует учесть, в новом shape-файле названия полей будут изменены на новые, вида input.field1, input.field2,..., table.field1, table.field2 и т.д., т.е. в новой таблице названия полей будут указывать и источник. Так как существует ограничение на длину названия поля, то это может привести к ухудшению читаемости названия поля. Для начала можно укоротить названия входного shape-файла и таблицы и самих названий полей.

Более правильным решением является переназначение названий полей:

<pre>ogr2ogr -sql "select input.field1 AS FIELD1, table.field2 AS FIELD2 from input LEFT JOIN 'table.csv'.table ON input.id = table.IDINT" output.shp input.shp</pre>

==Генерализация==
Один из самых простых вариантов упрощения - отбрасывание разрядов значений координат после запятой. Ключ <code>-lco COORDINATE_PRECISION=1</code> сколько оставить разрядов после запятой.

<pre>ogr2ogr -f "GeoJSON" -lco COORDINATE_PRECISION=1 output.json input.shp</pre>

Результирующие координаты будут приведены к форме DD.D, например: 75.158028 -> 75.200000, оставшиеся нули (если нужна минификация) нужно убирать уже в текстовом представлении, например таким регулярным выражением:

<pre>Find: "\.0([,\]])"
Replace: "$1"</pre>

== Работа с PostreSQL/PostGIS ==

Вставка (добавление) записей в таблицу PostgreSQL данных из файла data.shp. Таблица должна существовать и иметь такие же поля, как и shp-файл.

<pre>ogr2ogr -append -t_srs "+init=epsg:4326" -f PostgreSQL PG:"host=адрес user=имя_пользователя dbname=имя_базы" data.shp</pre>

Перезаписывает test таблицу PostgreSQL данными из файла test.tab Таблица не обязана существовать.

<pre>ogr2ogr -append -overwrite -s_srs "+init=epsg:4326" -f PostgreSQL PG:"host=адрес user=имя_пользователя dbname=имя_базы" test.tab</pre>

Перезаписывает данные из файла data в таблицу PostgreSQL. Таблица будет носить имя не data, а test1. Таблица test1 не обязана существовать.

<pre>ogr2ogr -append -overwrite -t_srs "+init=epsg:4326" -f "PostgreSQL" PG:"host=адрес user=имя_пользователя dbname=test" data.shp -nln test1</pre>

Наоборот: из таблицы PostgreSQL "adm" базы ipc конвертирует в allei.tab формата MapInfo.

<pre>ogr2ogr -f "MapInfo File" allei.tab PG:"host=адрес user=пользователь dbname=ipc" "adm"</pre>

Из таблицы PostgreSQL "adm" базы ipc конвертирует в shape-файл с использованием выражения sql.

<pre>ogr2ogr -f "ESRi Shapefile" output.shp PG:"host=адрес user=пользователь dbname=ipc" -sql "SELECT * from adm"</pre>

GDAL и кириллица в именах файлов Windows

2013-12-18T23:07:56Z

Boris:

{{Статья|Черновик}}
{{Аннотация|Утилиты GDAL/OGR и русские буквы в именах файлов и путей Windows. Рецепт использования кодировки UTF-8.}}
== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

=== Решение получено, но ... . Опять "но" ===

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

=== Продолжаем исследование ===
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

=== Решение ===
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

=== Примеры: ===
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* === Py-скрипт ===
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>
== Итог ==
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире "--", описанные в [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html [Gdal-dev] GDAL General Command Line Processor], т.к. эти опции несовместны с опцией '''--optfile filename''' .

GDAL и кириллица в именах файлов Windows

2013-12-18T23:03:16Z

Boris:

{{Статья|Черновик}}
== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

=== Решение получено, но ... . Опять "но" ===

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

=== Продолжаем исследование ===
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

=== Решение ===
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

=== Примеры: ===
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* === Py-скрипт ===
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>
== Итог ==
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире "--", описанные в [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html [Gdal-dev] GDAL General Command Line Processor], т.к. эти опции несовместны с опцией '''--optfile filename''' .

GDAL и кириллица в именах файлов Windows

2013-12-18T22:58:00Z

Boris: /* Итог */

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

=== Решение получено, но ... . Опять "но" ===

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

=== Продолжаем исследование ===
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

=== Решение ===
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

=== Примеры: ===
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* === Py-скрипт ===
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>
== Итог ==
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире "--", описанные в [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html [Gdal-dev] GDAL General Command Line Processor], т.к. эти опции несовместны с опцией '''--optfile filename''' .

GDAL и кириллица в именах файлов Windows

2013-12-18T22:47:05Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

=== Решение получено, но ... . Опять "но" ===

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

=== Продолжаем исследование ===
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

=== Решение ===
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

=== Примеры: ===
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ==== EXE-файл ====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* === Py-скрипт ===
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>
== Итог ==
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире "--", описанные в [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html [Gdal-dev] GDAL General Command Line Processor], т.к. эти опции несрвместны с опцией '''--optfile filename''' .

GDAL и кириллица в именах файлов Windows

2013-12-18T22:44:25Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

==== Решение получено, но ... . Опять "но" ====

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

==== Продолжаем исследование ====
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

==== Решение ====
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

==== Просмотр результатов: ====
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ===== EXE-файл =====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ===== EXE-файл =====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>
=== Итог ===
Решение найдено. Но т.к. костыли не заменяют ног, то кроме неудобства связанно с необходимостью для всех утилит создать Bat-Файлы со специальными настройками, и помнить внесенные изменения на случай выхода новой версии утилит или библиотеки в целом, при таком подходе мы лишились возможности в ряде случаев использовать команды, начинающиеся с двойного тире "--", описанные в [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html [Gdal-dev] GDAL General Command Line Processor], т.к. эти опции несрвместны с опцией '''--optfile filename''' .

GDAL и кириллица в именах файлов Windows

2013-12-18T22:38:24Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 ==
=== Анализ ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

==== Решение получено, но ... . Опять "но" ====

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

==== Продолжаем исследование ====
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

==== Решение ====
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "оболочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемые из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через параметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py"
if "%1"=="" goto iExit
if "%2"=="" @python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %~1
if "%2"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
if "%1"=="" @ogrinfo
if "%1"=="" goto iExit
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
ogrinfo --optfile "%iTmp%"
:iExit
@endlocal
</syntaxhighlight>

==== Просмотр результатов: ====
Приведенный выше BAT файлы сработали одинаково и в случае верных данных,

* ===== EXE-файл =====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.TAB"
</syntaxhighlight>
<pre>
Active code page: 65001
Had to open data source read-only.
INFO: Open of `f:\20 набор тестовых файлов\tsp.TAB'
using driver `MapInfo File' successful.
1: tsp (Point)
</pre>
* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
</syntaxhighlight>

<pre>
Active code page: 65001
0...10...20...30...40...50...60...70...80...90...100 - done.
</pre>

и в случае, когда входные данные породили сообщение об ошибке:
* ===== EXE-файл =====
<syntaxhighlight lang="bash">
F:\21>ogrinfoF.bat "f:\20 набор тестовых файлов\tsp.T__"
</syntaxhighlight>
<pre>
Active code page: 65001
FAILURE:
Unable to open datasource `f:\20 набор тестовых файлов\tsp.T__' with the following drivers.
-> FileGDB
-> ESRI Shapefile
...
</pre>

* ==== Py-скрипт ====
<syntaxhighlight lang="bash">
F:\21>gdal_mergeF.bat -o "результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__"
</syntaxhighlight>
<pre>
Active code page: 65001
ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.t__' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

GDAL и кириллица в именах файлов Windows

2013-12-18T21:56:26Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 (для правой и левой ноги - разные) ==
=== Костыль №3 ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

==== Решение получено, но ... . Опять "но" ====

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

==== Исследование ====
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

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

==== Решение ====
Оно показалось очевидным:
# устанавливаем кодировку "приятную" нам и "облочке командной строки". я выбрал UTF-8 или CP65001 ( космополитизм, однако ...);
# сохраняем параметры программы, получаемыек из командной строки в выбранный файл в выбранной кодировке;
# считываем это файл через праметр '''--optfile filename'''
# и исправив только BAT файлы, что IMHO проще и безопасней для будущего, чем править скрипты, получаем весь спектр симовлов UTF-8 в именах файлов и других праметрах.

В результате получился для '''dal_merge.py''' вот такой BAT-Файл '''dal_mergeF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo off
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@rem echo %iTmp%
@echo %ARGV%>"%iTmp%"
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" --optfile "%iTmp%"
@endlocal
</syntaxhighlight>

Больше того, и скомпилированные в EXE-файлы утилиты то же через это способ можно перевести на общение через UTF-8. Для '''ogrinfo.exe''' получился вот такой BAT-Файл '''ogrinfoF.bat'''
<syntaxhighlight lang="bash">
@setlocal
@echo on
@chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
set ARGV=%*
set iTmp=%tmp%\%RANDOM%_%~n0_%RANDOM%.tmp
@echo %iTmp%
echo %ARGV%>"%iTmp%"
@rem chcp 1251
ogrinfo --optfile "%iTmp%"
@endlocal
</syntaxhighlight>

GDAL и кириллица в именах файлов Windows

2013-12-18T21:40:24Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 (для правой и левой ноги - разные) ==
=== Костыль №3 ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

==== Решение получено, но ... . Опять "но" ====

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

==== Исследование ====
Пришлось искать смысл этой функции. Кода не нашел, но нашел описание идеи [http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor] и указание на то, что она входит во все утилиты (естественно все проверить мне не удалось) и задумана она для облегчения обработки сложных входных строк!
И что гораздо важней, есть порождаемый этой функцией параметр
<pre>
--optfile filename: expand an option file into the argument list.
</pre>
который должны понимать все утилиты GDAL/ORG, и который согласно писанию предназначен для считывания параметров командной строки из файла.

==== Вывод ====
И этот параметр позволяет поместить в файл параметры в полностью контролируемой кодировке, а потом программе считать их без

GDAL и кириллица в именах файлов Windows

2013-12-18T21:31:07Z

Boris:

== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

В примере видно, что при установленной по умолчанию кодировке командной строки (CP866), вывод на экран функциями печати производится в кодировке '''CP1251''', которая является кодировкой Windows, установленной в системных настройках. Этот интересный факт, пригодится нам для позже.

== Решение проблемы. Костыль №1 ==
Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

===Вывод:===
Установите переменную окружения '''GDAL_FILENAME_IS_UTF8''' в значение '''NO''', и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

=== Технические детали: ===
В процессе обсуждения такого прискорбного для русско-пишущих факта, всплыло указание на то, что эта переменная дана не от хорошей жизни, а как подпорка для тех, кто живет "неправедной" жизнью с вредными кодировками (во вредных ОС), в то время как "прогрессивное человечество" использует кодировку [http://ru.wikipedia.org/wiki/Utf-8 UTF-8], которая и встроена как основная в библиотеку GDAL/OGR. По мнению обсуждавших тему (я сам исходные коды не читал, и тут все принимаю на веру), внутренние функции GDAL/OGR оперируют строками в UTF-8, и этими же строками UTF-8 пытаются открывать файлы, если переменная окружения '''GDAL_FILENAME_IS_UTF8''' не установлена или имеет значение '''YES'''.

Так же было высказано обоснованное предположение, что Windows скорее всего имена файлов хранит в кодировке [http://ru.wikipedia.org/wiki/UTF-16 UTF-16], но потом, для пользователя, они оказывают в разных кодировках, в зависимости от места и ситуации обращения к ним. Для игрищ с кодировками консоли Windows ( [http://ru.wikipedia.org/wiki/Cmd.exe командный процессор '''cmd''']) служит команда <code>CHCP</code>. Которая как оказалось, позволяет устанавливать кодировку UTF-8 командой <code>CHCP 65001</code>. К стати, Windows 7 кодировки UTF-16 c номерами 1200 и 1201, устанавливать не позволяет.

Что можно утверждать точно, так это то, что интерпретатор языка [ Python 2.7], оперирует строками в кодировке UTF-8.

=== И все бы было хорошо, если бы не ... : ===
==== Общая неудовлетворенность запретом UTF-8: ====
Ну в самом деле, у всех (видимо англоязычных) есть, а нам - нельзя. А вдруг к русскому языку захочется еще немецких [http://ru.wikipedia.org/wiki/%D0%A3%D0%BC%D0%BB%D0%B0%D1%83%D1%82_(%D0%B4%D0%B8%D0%B0%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B7%D0%BD%D0%B0%D0%BA) умляутов] или другой какой UNICODE экзотики, а тут нельзя - оставайтесь только в пределах одной кодовой страницы, к тому же неизвестно где выставленной.

==== Проблемы со скриптами на языке Python: ====
Если предыдущий абзац - это блаж, без которой можно обойтись в работе, то вот такой неприятный сюрприз с вызовом утилиты ''''gdal_merge.bat''' из настроенной казалось системы:
<pre>
C:\OSGeo4W64\bin>set GDAL_FILENAME_IS_UTF8
GDAL_FILENAME_IS_UTF8=NO

C:\OSGeo4W64\bin>al_merge.bat -o "F:\21\результат.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif" "F:\20 набор тестовых файлов\x2_9140_N-37-28-Г.tif"
ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

ERROR 4: `F:\20 \x2_9140_N-37-28-.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

Traceback (most recent call last):
File "C:\OSGEO4~1\bin\gdal_merge.py", line 509, in <module>
sys.exit(main())
File "C:\OSGEO4~1\bin\gdal_merge.py", line 392, in main
ulx = file_infos[0].ulx
IndexError: list index out of range
</pre>

огорчает. И "танцы с бубном": как то установка всех пришедших в голову кодовых страниц, комбинация кодовой страницы '''65001''' и переменной окружения '''GDAL_FILENAME_IS_UTF8=YES''' результата не дают:

<syntaxhighlight lang="bash">
@setlocal
chcp 65001
Set GDAL_FILENAME_IS_UTF8=YES
@python "%OSGEO4W_ROOT%\bin\gdal_merge.py" %*
@endlocal
</syntaxhighlight>

Не работает приведенный вариант, хоть ты тресни. При этом, если вывести результат командной строки в файл, видно, что текст создается в кодировке UTF-8 (65001).

== Решение проблемы. Костыль №2 (надпиленный) ==
Как видно выше, на самом деле BAT-файл '''dal_merge.bat''' - это всего навсего обертка на python-скриптом '''dal_merge.py'''. Достаточно исправить имя файла, так что бы не было злосчастных русских букв, и вперед - все заработает как было задумано. Хоть с '''GDAL_FILENAME_IS_UTF8=YES''', хоть '''GDAL_FILENAME_IS_UTF8=NO'''.
Очевидное решение для этого - скопировать русский файл во временный каталог с именем без русских букв, а потом использовать эту копию.

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

=== Описание решаемой задачи ===
которая показала, что так просто с этой проблемы не обойтись.
Так сложилось, что надо было мне сперва создать очень много файлов с русскими буквами, а потом еще и обработать их по всякому:
# Были исходные данные в виде 10 больших GTIFF файлов, размером от 3 до 9 Гигабайт.
# Файлы немного перекрывались, поскольку были результатом обработки многих сцен, собранных для трансформации.
# Надо было разложить фрагменты этих растров по стандартным планшетам М1:50000.
# В названиях планшетов есть русская буквы. Замена этой русской буквы на латинскую или цифру всегда приводила к путанице, да и основной пользователь продукта высказал мнение, что "русская буква есть принятый стандарт, от которого отойти - нельзя".
# После того как все было нарезано, естественно оказалось, что отдельные планшеты, вырезанные только из одного большого растра - не полны, т.к. их фрагмент пришелся на другой растр. И эти фрагменты необходимо объединить в одни планшет.
# Для полноты безобразия, ряд пользователей (из особо продвинутых) затребовал, что бы полученные планшеты были слиты в один растр, покрывающий некоторую область, а то ихний ...кад много мелких файлов (по 200 МБ) не понимает.

Вот для таких ритуальных танцев пришлось использовать GDAL/OGR в автономном режиме, потому как экранные ГИС умирали еще на стадии открытия одного TIF файла. И все удавалось победить, пока не дошло утилит, которые использовали скрипты на python'е. Тут работа крепко встала. Пока не было найдено решение с переименованием.

=== Костыль №2 (надпиленный) ===
Какое-то время казалось, что все хорошо. Пока не пришло время смотреть промежуточный результат. И тут стало ясно, что при сбое в утилите '''gdal_merge''', переименованные файлы назад к своим именам не возвращаются. Больше того и понять как они раньше назывались дело не простое. Так что костыль оказался "надпиленный" и навернуться, опираясь на него, можно очень больно.

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

Отсюда возникла задача победить таки этот зловредный UTF-8. Чему и посвящен остаток статьи.

== Решение проблемы. Костыль №3 (для правой и левой ноги - разные) ==
=== Костыль №3 ===
В результате обсуждений на форуме, упомянутых выше, стало ясно, что придется смотреть коды программ, что бы понять чего там не срастается с этими русскими буквами. Началось все со скрипта '''dal_merge.py''', как наиболее актуального. И быстро стало ясно, что предположение о том, что путаница начинается в момент открытия файла через функции GDAL верна только отчасти. Функция <pre>gdal.Open( filename )</pre> была готова открывать файлы в системной кодировке CP1251, если '''GDAL_FILENAME_IS_UTF8=NO''', или в кодировке UFT-8, если '''GDAL_FILENAME_IS_UTF8=YES'''. Кодировку CP866, стандартную для консоли не хотела видеть ни в каком случае. Но как оказалось на вход этой функции всегда приходила строка кодированная в UTF-8, даже если по факту данные в ней не имели ничего общего с этой кодировкой.

Анализ показал, что в упомянутом скрипте, это работа вот такого кода:
<pre>
if argv is None:
argv = sys.argv
argv = gdal.GeneralCmdLineProcessor( argv )
</pre>
Не зависимо от настроек функция [http://www.sourcecodebrowser.com/gdal/1.6.2/namespacegdal.html#a1103e0dd344e3912067a908915d0814f gdal.GeneralCmdLineProcessor] считала, что разбирает строку в UTF-8. Попытки найти, что же она такое там делает, и как ее убедить так не делать, не увенчались успехом.

Но стало очевидно, что если строку с ней закомментировать, то дальше обработка полученных параметров командной строки строится на значении переменной '''GDAL_FILENAME_IS_UTF8''':
# '''GDAL_FILENAME_IS_UTF8=NO''' - кодовая страница должна быть CP1251;
# '''GDAL_FILENAME_IS_UTF8=YES''' - кодовая страница должна быть UTF-8;

==== Решение получено, но ... Опять ""но" ====

Решение получено - надо закомментировать строку с '''gdal.GeneralCmdLineProcessor'''. Но тут есть пара "но":
# ведь скрипты могут из измениться в новых версиях, и вспомнить такие подробности, именно эту строку надо "извести" - это не так просто. Хотя бы только для этого надо оставить память в виде статьи.
# gdal.GeneralCmdLineProcessor - что-то ведь должен делать, кроме как портить входные строки. Для чего то он был задуман.

==== Костыль №3 ====
==== Решение получено, но ... Опять ""но" ====

[http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor]

[http://lists.osgeo.org/pipermail/gdal-dev/2004-April/002369.html gdal.GeneralCmdLineProcessor]

GDAL и кириллица в именах файлов Windows

2013-12-18T18:55:48Z

Boris:

= GDAL и русские буквы в именах файлов и путей Windows =
== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими буквами, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="bash">
F:\21>gdalinfo результат.tif
</syntaxhighlight>
<pre>
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.
</pre>

<syntaxhighlight lang="bash">
F:\21>chcp 1251
F:\21>gdalinfo результат.tif
</syntaxhighlight>

<pre>
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</pre>

Тема обсуждалась на нашем форуме и закончилась [http://gis-lab.info/forum/viewtopic.php?f=30&t=9182&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p54406 диагнозом]. Расширенная версии обсуждения русских букв: [http://gis-lab.info/forum/viewtopic.php?f=30&t=15093&hilit=%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B5+gdal#p100080 GDAL и русские буквы в именах файлов Windows].

Вывод:
Установите переменную окружения GDAL_FILENAME_IS_UTF8 в значение NO, и при работе в пределах одной кодовой страницы - будет вам счастье:
<pre>
set GDAL_FILENAME_IS_UTF8=NO
</pre>

GDAL и кириллица в именах файлов Windows

2013-12-18T18:32:33Z

Boris: /* GDAL и русские буквы в именах файлов Windows */

= GDAL и русские буквы в именах файлов и путей Windows =
== Вступление: ==
=== Утилиты GDAL/OGR краткие сведения: ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Богатство форматов, поддерживаемых библиотекой, позволяет использовать с огромным количеством ГИС-данных. Библиотека GDAL/OGR используется в [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal] коммерческих, свободных и открытых продуктах для операций над ГИС-файлами. Не упомянутый на странице [http://trac.osgeo.org/gdal/wiki/SoftwareUsingGdal Software Using GDAL] очень достойный (хотя и не очень дешевый ;) ) российский продукт [http://www.scanex.ru/ru/software/default.asp?submenu=imageprocessor&id=index SCANEX IMAGE PROCESSOR®], так же использует библиотеки GDAL/OGR.

Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в инсталяционном пакете присутствует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векторными данными. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.

О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].
Для специалиста, умеющего общаться с командной строкой, набор утилит представляет огромные возможности, часто не сопоставимые с многими пакетами "ГИС". Сильной стороной пакета является отсутствие необходимости визуализовать файлы во время работы, что сказывается на быстродействии его операций, а так же позволяет работать с файлами, размеры которых "убивают" многие графические редакторы и ГИС-программы.

=== Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows: ===
Это все были плюсы, к которым несомненно стоит отнести тот факт, что библиотека и утилиты открыты и бесплатны. Больше того библиотека находится в постоянном развитии. Вот с этого момента начинаются небольшие, но очень "кусачие" минусы. Останавливаться на перманентном изменении поведения отдельных частей библиотеки не имеет смысла, поскольку статья не про это. Есть люди, которые живут с этой библиотекой и ее развитием дружно, и к ним можно всегда постучаться за помощью. Проблемой является то, что часть нетривиальных случаев в поведении библиотеки приходится на пользователей Windows, которые стоят в стороне от тех, кто пишет "кросс-платформенные" библиотеки на Lunix. Из этого факта вырос неприятный сюрприз, что утилиты GDAL/OGR не "любят" русские буквы в именах путей и файлов Windows. Такая особенность возникла не сразу, а где то в процессе перехода от версии 1.6 к версии 1.9. С тех пор попытки передать программам имена с русскими, а скорее всего и символами любых других национальных алфавитов, выходящих за рамки [http://ru.wikipedia.org/wiki/ASCII ACSII], заканчивались как то так:

<syntaxhighlight lang="python">
F:\21>gdalinfo результат.tif
ERROR 4: `Ёхчєы№ЄрЄ.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'Ёхчєы№ЄрЄ.tif'.

F:\21>chcp 1251

F:\21>gdalinfo результат.tif
ERROR 4: `результат.tif' does not exist in the file system,
and is not recognised as a supported dataset name.

gdalinfo failed - unable to open 'результат.tif'.
</syntaxhighlight>

GDAL и кириллица в именах файлов Windows

2013-12-18T17:48:08Z

Boris: Новая страница: «== GDAL и русские буквы в именах файлов Windows == === Вступление: Утилиты GDAL/OGR не "любят" русские б…»

== GDAL и русские буквы в именах файлов Windows ==
=== Вступление: Утилиты GDAL/OGR не "любят" русские буквы в именах файлов Windows ===
[http://ru.wikipedia.org/wiki/GDAL GDAL/OGR] - это кросс-платформенная библиотека для обработки ГИС-информации, и растров, и векторов. Для программистов она представляет серьезный инструмент для создания ГИС-приложений. Кроме самих библиотек [http://www.gdal.org/index_ru.html GDAL] и [http://www.gdal.org/ogr/index.html OGR] в существует набор уже созданных утилит [http://www.gdal.org/gdal_utilities.html GDAL]/[http://www.gdal.org/ogr_utilities.html OGR], запускаемых из командной строки, которые позволяют выполнять многие операции над растровыми и векорными данными. Богатство форматов, поддерживаемых библиотекой, позволяет использовать ее к огромному количеству ГИС-данных. Часть утилит представлена в виде исполнимых (EXE) файлов, а часть в виде скриптов на языке Python.
О GDAL/OGR можно узнать на форуме в разделе [http://gis-lab.info/forum/viewforum.php?f=30 Программное обеспечение ‹ Свободные, бесплатные, открытые ГИС ‹ GDAL/OGR]. Один из вариантов установки дан в этой [http://gis-lab.info/qa/qgis-osgeo4w.html статье]. Мне известно, что утилиты командной строки так же входят состав ГИС [http://nextgis.ru/nextgis-qgis/ NextGIS QGIS].

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T23:01:47Z

Boris: /* Создание контура изображения */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю размера планшета приблизительно на 5%, для простоты создания буфера я перед созданием буфера пересчитываю их в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что нам необходимо было получить:

- 4 координаты 2-х углов сетки, которые лежат только в пределах обрезаемого (скорее разбираемого) растра и имеют ту же СК, что и обрезаемый растр.
Если это у нас есть, то вперед - интерационо разберем растр на части.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл '''Q1.MID''' (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог '''"root\1\"''', исходный файл находится по адресу '''"f:\test\test.tif"''':
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T23:01:11Z

Boris: /* Создание контура изображения */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю размера планшета приблизительно на 5%, для простоты создания буфера я перед созданием буфера пересчитываю их в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что нам необходимо было получить:
- 4 координаты 2-х углов сетки, которые лежат только в пределах обрезаемого (скорее разбираемого) растра и имеют ту же СК, что и обрезаемый растр.
Если это у нас есть, то вперед - интерационо разберем растр на части.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл '''Q1.MID''' (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог '''"root\1\"''', исходный файл находится по адресу '''"f:\test\test.tif"''':
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:57:27Z

Boris: /* Обрезка растра */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю размера планшета приблизительно на 5%, для простоты создания буфера я перед созданием буфера пересчитываю их в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл '''Q1.MID''' (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог '''"root\1\"''', исходный файл находится по адресу '''"f:\test\test.tif"''':
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:43:32Z

Boris: /* Обрезка растра */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю размера планшета приблизительно на 5%, для простоты создания буфера я перед созданием буфера пересчитываю их в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл Q1.MID (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог root\1\, исходный файл находится по адресу '''"f:\test\test.tif"''':
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:40:39Z

Boris: /* Создание контура изображения */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю размера планшета приблизительно на 5%, для простоты создания буфера я перед созданием буфера пересчитываю их в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл Q1.MID (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог root\1\, в нем же должна быть воссоздана структура исходных каталогов:
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:38:12Z

Boris: /* Небольшое отступление */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.
Идея нашей обработки - извлечение прямоугольных участков растра, заданных двумя вершинами. Для этого у '''gdal_translate''' есть два механизма - задать координаты растра и задать координаты в проекции растра, а программа сама пересчитает эти координаты в координаты растра (и выведет их нам при работе).

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю на 5% от размера планшета, пересчитанных в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл Q1.MID (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог root\1\, в нем же должна быть воссоздана структура исходных каталогов:
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:35:16Z

Boris: /* Постановка задачи */

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL 1.9.1 версии и MapInfo актуальной (9.5) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю на 5% от размера планшета, пересчитанных в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл Q1.MID (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог root\1\, в нем же должна быть воссоздана структура исходных каталогов:
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

GDAL+MapInfo: разрезаем изображение прямоугольной сеткой

2012-10-05T22:34:21Z

Boris:

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

Для решения задачи будет использоваться следующее ПО: утилиты GDAL ??? версии и MapInfo актуальной (???) версии. Ниже в командных инструкциях используется синтаксис командной строки Windows XP.

== Полигональная сетка ==
Полигональная сетка была создана в MapInfo, немного остановимся на ее обработке ниже, но сам этап создания сетки рассматривать не будем.

=== Небольшое отступление ===
Самый известный вариант сетки — это сетка планшетов СК-42 (и аналогичных). Она стандартна, удобно создана для разных масштабов, и имеется у всех, кому нужна. С ней есть только один небольшой минус — она не прямоугольна. А смысл в том, чтобы резать изображение, не нарушая его пиксельной структуры — без пересчетов и искажений. Утилита '''gdalwarp''' позволяет обрезать изображение векторной сеткой, записанной в файл. Это не наш случай, т.к. он производит пересчет пикселей под векторный контур.

== Создание контура изображения ==

Для начала создадим внешний контур изображения. Тут есть два способа — простой и сложный, выбор зависит от свойств конкретных данных и частностей задачи.
* '''Простой''' способ – простая рамка изображения, которая создаётся утилитой '''gdaltindex'''.
Например, для всех растров в папках, начинающихся с «MRGN_» :
for /d %b in (MRGN_*) do @for %a in (%b\*.tif) do if exist "%~fa" gdaltindex -skip_different_projection MRGN_SP5_2011_index.shp "%~fa"
для одной папки с растрами синтаксис имеет вид:
gdaltindex -skip_different_projection index.shp "*.tif"

* '''Сложный''' способ, который учитывает, что растр может занимать только часть изображения, а часть растра нас не интересует, т.к. имеет «черное» поле (NODATA=0). В этом случае, я делаю еще «пару танцев с бубном»:
1. Cоздадим новый растр из предположения, что есть NODATA=0 и все остальное > 0. Используем утилиту '''gdal_calc''', чтобы вычленить ненулевые значения (в примере снова обработка целой папки с растрами TIF):
for /r %a in (*.tif) do gdal_calc -A "%~fa" --outfile="%~dpna_c.tif" --calc="(A>0)*127+(A==0)*0" --NoDataValue=0 --type=Byte –overwrite
2. Сжимаем полученные файлы с помощью опции COMPRESS=CCITTFAX4 с очевидным уменьшением разрядности до 1 бита через '''gdal_translate''':
for /d %b in (MRGN_*) do @for %a in (%b\%~b_c.tif) do gdal_translate -of "GTiff" -a_nodata 127 -co "NBITS=1" -co "TFW=YES" -co "COMPRESS=CCITTFAX4" "%~fa" "%~dpna_msk.tif"
Это делаем для того, чтобы однозначно избавиться от всех значений больше 0, и радикально уменьшить размер растра, если мы задумаем его хранить как маску.

Создаем контура значимых (непустых) частей снимков через утилиту векторизации '''gdal_polygonize''':
for /d %b in (MRGN_*) do @for %a in (%b\*_c_msk.tif) do if exist "%~fa" gdal_polygonize "%~fa" -b 1 -f "ESRI Shapefile" %b\%~na_poly.shp

Теперь надо открыть полученный вектор в какой-то ГИС. MapInfo часто не может открыть векторные данные, получившиеся в результате работы GDAL-утилит, т.к. в них есть тестовые поля длиной 255 символов (у MapInfo ограничение длины строки в 254), так что контур можно перевести программно через '''ogr2ogr''':
ogr2ogr -f "MapInfo File" MRGN_SP5_2011_poly_mi.tab MRGN_SP5_2011_poly.shp

Темы объединения векторов касаться не будем, это тоже можно сделать с помощью ogr2ogr.

Откроем контур (-а) растра (-ов) в MapInfo. С вероятностью 25%, в случае когда мы векторизовали значимый контур изображения через gdal_polygonize, в векторе будут присутствовать мелкие дырки от пикселей, которые имели значение NODATA внутри значимой части изображения.

* Для борьбы с ними в MapInfo разгруппируем все составные объекты, превращая «дырки» в отдельные объекты.
* После этого удалим все объекты, имеющие площадь меньше некоторой критичной (например, 1 кв.км). Должны остаться только контура изображений.

Теперь откроем контуры планшетов в ГИС. Проделаем с ними следующие превращения (большинство избыточны):
* Увеличим размер каждого планшета на некоторую величину (не обязательно, но если потом придется выводить растр с перекрытием, это даст запас пикселей по краям). Я увеличиваю на 5% от размера планшета, пересчитанных в метры.
* Переводим полученный вектор в проекцию (или систему координат) растра.
* Новый растр открываем и находим для каждого контура MBR (minimum bounding rectangle). В MapInfo это стандартная функция, которую можно применить к объектам слоя, затирая их (это команда на MapBasic, которая выполняется в окне MapBasic внутри MapInfo):
update cutSHP_m50_000_UTM37 set obj=MBR(buffer(obj,20,2000,"m"))
что буквально означает следующее:
"Для всех объектов слоя cutSHP_m50_000_UTM37 создать MBR для буфера вокруг каждого объекта с приращением 2000 метров и числом вершин при моделировании дуги равным 20".
* Надо расширить атрибутику векторных данных, т.к. в дальнейшем нам потребуются числовые значения координат вершин планшетов (под "планшетами" здесь понимаются «геометрические объекты сетки»). Этот пункт обязателен для исполнения (ниже станет ясно, почему):
Alter Table "cutSHP_m50_000_UTM37" ( add ulX float, ulY float, lrX float, lrY float)
* Теперь надо физически удалить планшеты, которые не пересекают значимый контур изображения. В MapInfo отбор таких объектов делается с помощь пространственного запроса. В этом же пункте можно удалить и избыточные объекты сетки, т.к. мы их создали с перекрытием.
* Теперь существенный момент: надо обрезать планшеты внешней границей растра (той, что получена в результате работы gdal_polygonize). Это обязательно надо сделать, т.к. планшеты, которые будут выступать за физические границы растра, не будут обработаны gdal_translate. В MapInfo это делается стандартной командой «Erase outside».
* Последний пункт – вычисление координат углов каждого планшета и сохранение этих координат в ранее созданные поля ulX float, ulY float, lrX float, lrY float. В MapInfo для этого существуют стандартные функции и команда Update:
update cutSHP_m50_000_UTM37 set ulx=ObjectGeography( object, 1 ),uly=ObjectGeography( object, 4 ),lrx=ObjectGeography( object, 3 ),lry=ObjectGeography( object, 2 )
* '''Внимание!''' Параметр ''-projwin'' у '''gdal_translate''' имеет вид
-projwin ulx uly lrx lry
Такая запись отличается от обычной, которая начинается с ЛЕВОГО НИЖНЕГО угла. Здесь, как в растре – начало в ЛЕВОМ ВЕРХНЕМ углу, а вторая пара координат соответствует ПРАВОМУ НИЖНЕМУ углу.
* Сохраняем векторные данные в формат MIF/MID так, чтобы они имели следующий вид:
Id, ulx, uly, lrx, lry
Id – уникальный номер (не обязательно, но полезно, чтобы задать упорядоченные имена для создаваемых файлов-фрагментов), X -координата верхнего левого угла, Y - координата верхнего левого угла, X координата нижнего правого угла, Y координата нижнего правого угла.

Это может быть не только формат MIF/MID, но и любой другой текстовый формат. В этом случае будем использовать только MID – текстовый файл атрибутивных данных. Все, что нам нужно – это координаты углов планшетов, чтобы извлекать подмножества из исходного растра.

Все «танцы с бубном» завершены.

Повторим, что собственно нам обязательно надо получить:
* 4 координаты углов сетки;
* эти координаты должны лежать только в пределах обрезаемого (скорее разбираемого) растра;
* иметь ту же СК, что и обрезаемый растр.

== Обрезка растра ==
Само использование GDAL, а именно, '''gdal_translate''', гораздо короче:
# Создаем набор команд для вычисления контуров в виде BAT-файла.
# Команда выполняется в каталоге, где лежит файл Q1.MID (так я назвал экспорт координат углов), файлы выполнения сохраняются в каталог root\1\, в нем же должна быть воссоздана структура исходных каталогов:
for /f "tokens=1-5 delims=," %a in (Q1.MID) do @echo @if not exist "root\1\test_%~a.tif" gdal_translate -of GTIFF -projwin %b %c %d %e -a_nodata 0 -co "TFW=YES" -co "compress=LZW" "f:\test\test.tif" "root\1\test_%~a.tif">>root\1\do_%~a.bat
# Можно сразу же запускать команды на выполнение в цикле for командной строки DOS, но создание набора BAT-файлов позволяет воспользоваться параллельным вычислением фрагментов или вернуться к прерванному вычислению, если понадобиться.

Разберём командные инструкции, написаные выше.
Команда
for /f "tokens=1-5 delims=," %a in (Q1.MID) do
означает "Построчно считать файл '''Q1.MID''' и выполнить над каждой строчкой операцию, записанную после '''do'''":
* Использовать в качестве разделителя параметров строки символ «,»
* Используя разделитель, получить 5 параметров – переменные от а до e
* %а – уникальный номер, %b %c %d %e - координаты углов планшета из файла '''Q1.MID'''
Если не существует файл с именем "root\1\test_%~a.tif" , то:
* Выполнить команду gdal_translate
* над исходным файлом '''"f:\test\test.tif"'''
* с результирующим файлом '''"root\1\test_%~a.tif"'''
* '''-a_nodata 0''' - условием "нет данных" (NODATA) для пикселей со значение 0 во всех каналах
* '''-of GTIFF''' - выходным форматом GeoTIFF
* '''-co "TFW=YES" -co "compress=LZW"''' с дополнительными параметрами «Создавать world file» и «Сжимать растр алгоритмом LZW»
* '''-projwin %b %c %d %e''' – вырезать фрагмент, заданный указанными координатами, в системе координат растра (gdal_translate переведет их в координаты растра перед тем, как вырезать фрагмент, о чем программа информирует нас по ходу выполнения). Если границы выйдут за пределы растра, программа завершится сбоем и сообщением об ошибке.

И, наконец, запускаем на выполнение все созданные BAT-файлы:
for %a in (do_*.bat) do "%~fa"

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T22:09:21Z

Boris: /* Введение */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Вступление ===
Цель данной статьи не только показать как выполнить конкретную задачу по вычислению расстояний между точками, заданными в геодезической (географической) системе координат в градусах, что является нормой для приемников сигнала GPS/Глонасс, через перевод координат в спроецированные координаты в метрах, но продемонстрировать некоторые типичные подходы при работе в ГИС Мапинфо, в том числе и неявные способы, открывающиеся при использовании окна Мапбайсик, в который Мапинфо выводит практически все команды, вызываемые через стандартный интерфейс.
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

''Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 (а должны и ранее). Исключения могут быть связаны только с форматом файла Excel, в котором созданы исходные данные, и который умеете читать "на прямую" программа Мапифно.''

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высотой над уровнем моря, отрицательными координатами или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести расчет в Excel даже если бы мы использовали функции для пересчета сферических координат, видимо полученных от устройства GPS, в плановые метровые. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим из таблицы все строки, содержащие некорректные данные, нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений, мы получили пределы, в которые вписываются все координаты измерений. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояниями (переведенными на плоскость спроецированной поверхности) и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать обычную формулу Пифагора для 3-х мерного пространства.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. В этом же окне присвоим таблице систему координат - установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. [http://gis-lab.info/forum/viewtopic.php?f=17&t=4708&hilit=+%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#p21658 Обсуждение проблемы смотрим вот здесь]
Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Далее для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

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

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]

''Примечание: приведенная программа является собственной разработкой (с)2011. В новые версии мапинфо входит улучшенный аналог, который позволяет задавать построение множества геобъектов из наборов точек, в то время как эта программа создает единственный объект на основании входного списка. Более функциональные программы используют для определения порядка создания вершин два индекса - первый задает объекты, второй, порядок вершин в объекте. Приведенные в статье программа не использует индексов, а создает вершины в том же порядке как они записаны в исходных файлах.
Кроме того возможно создание геообъектов через программы библиотеки GDAL/ORG, как это описано в статье ''[http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления в MapInfo производятся только по двумерным координатам при геообъекте, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T22:07:26Z

Boris: /* Вступление */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

''Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 (а должны и ранее). Исключения могут быть связаны только с форматом файла Excel, в котором созданы исходные данные, и который умеете читать "на прямую" программа Мапифно.''

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высотой над уровнем моря, отрицательными координатами или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести расчет в Excel даже если бы мы использовали функции для пересчета сферических координат, видимо полученных от устройства GPS, в плановые метровые. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим из таблицы все строки, содержащие некорректные данные, нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений, мы получили пределы, в которые вписываются все координаты измерений. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояниями (переведенными на плоскость спроецированной поверхности) и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать обычную формулу Пифагора для 3-х мерного пространства.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. В этом же окне присвоим таблице систему координат - установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. [http://gis-lab.info/forum/viewtopic.php?f=17&t=4708&hilit=+%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#p21658 Обсуждение проблемы смотрим вот здесь]
Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Далее для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

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

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]

''Примечание: приведенная программа является собственной разработкой (с)2011. В новые версии мапинфо входит улучшенный аналог, который позволяет задавать построение множества геобъектов из наборов точек, в то время как эта программа создает единственный объект на основании входного списка. Более функциональные программы используют для определения порядка создания вершин два индекса - первый задает объекты, второй, порядок вершин в объекте. Приведенные в статье программа не использует индексов, а создает вершины в том же порядке как они записаны в исходных файлах.
Кроме того возможно создание геообъектов через программы библиотеки GDAL/ORG, как это описано в статье ''[http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления в MapInfo производятся только по двумерным координатам при геообъекте, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T22:07:08Z

Boris: /* Порядок обработки данных */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Вступление ===
Цель данной статьи не только показать как выполнить конкретную задачу по вычислению расстояний между точками, заданными в геодезической (географической) системе координат в градусах, что является нормой для приемников сигнала GPS/Глонасс, через перевод координат в спроецированные координаты в метрах, но продемонстрировать
=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

''Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 (а должны и ранее). Исключения могут быть связаны только с форматом файла Excel, в котором созданы исходные данные, и который умеете читать "на прямую" программа Мапифно.''

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высотой над уровнем моря, отрицательными координатами или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести расчет в Excel даже если бы мы использовали функции для пересчета сферических координат, видимо полученных от устройства GPS, в плановые метровые. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим из таблицы все строки, содержащие некорректные данные, нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений, мы получили пределы, в которые вписываются все координаты измерений. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояниями (переведенными на плоскость спроецированной поверхности) и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать обычную формулу Пифагора для 3-х мерного пространства.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. В этом же окне присвоим таблице систему координат - установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. [http://gis-lab.info/forum/viewtopic.php?f=17&t=4708&hilit=+%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#p21658 Обсуждение проблемы смотрим вот здесь]
Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Далее для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

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

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]

''Примечание: приведенная программа является собственной разработкой (с)2011. В новые версии мапинфо входит улучшенный аналог, который позволяет задавать построение множества геобъектов из наборов точек, в то время как эта программа создает единственный объект на основании входного списка. Более функциональные программы используют для определения порядка создания вершин два индекса - первый задает объекты, второй, порядок вершин в объекте. Приведенные в статье программа не использует индексов, а создает вершины в том же порядке как они записаны в исходных файлах.
Кроме того возможно создание геообъектов через программы библиотеки GDAL/ORG, как это описано в статье ''[http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления в MapInfo производятся только по двумерным координатам при геообъекте, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T21:59:13Z

Boris: /* Порядок обработки данных */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Вступление ===
Цель данной статьи не только показать как выполнить конкретную задачу по вычислению расстояний между точками, заданными в геодезической (географической) системе координат в градусах, что является нормой для приемников сигнала GPS/Глонасс, через перевод координат в спроецированные координаты в метрах, но продемонстрировать
=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

''Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 (а должны и ранее). Исключения могут быть связаны только с форматом файла Excel, в котором созданы исходные данные, и который умеете читать "на прямую" программа Мапифно.''

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высотой над уровнем моря, отрицательными координатами или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести расчет в Excel даже если бы мы использовали функции для пересчета сферических координат, видимо полученных от устройства GPS, в плановые метровые. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим из таблицы все строки, содержащие некорректные данные, нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений, мы получили пределы, в которые вписываются все координаты измерений. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояниями (переведенными на плоскость спроецированной поверхности) и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать обычную формулу Пифагора для 3-х мерного пространства.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. В этом же окне присвоим таблице систему координат - установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. [http://gis-lab.info/forum/viewtopic.php?f=17&t=4708&hilit=+%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#p21658 Обсуждение проблемы смотрим вот здесь]
Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Далее для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

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

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]

''Примечание: приведенная программа является собственной разработкой (с)2011. В новые версии мапинфо входит улучшенный аналог, который позволяет задавать построение множества геобъектов из наборов точек, в то время как эта программа создает единственный объект на основании входного списка. Более функциональные программы используют для определения порядка создания вершин два индекса - первый задает объекты, второй, порядок вершин в объекте. Приведенные в статье программа не использует индексов, а создает вершины в порядке том же порядке как они записаны в исходных файлах.
Кроме того возможно создание геообъектов через программы библиотеки GDAL/ORG, как это описано в статье ''[http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления в MapInfo производятся только по двумерным координатам при геообъекте, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T21:28:56Z

Boris: /* Порядок обработки данных */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

''Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 . Исключения могут быть связаны только с форматом файла Excel, в котором созданы исходные данные, и который умеете читать "на прямую" программа Мапифно.''

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высотой над уровнем моря, отрицательными координатами или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести расчет в Excel даже если бы мы использовали функции для пересчета сферических координат, видимо полученных от устройства GPS, в плановые метровые. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим из таблицы все строки, содержащие некорректные данные, нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений, мы получили пределы, в которые вписываются все координаты измерений. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояниями (переведенными на плоскость спроецированной поверхности) и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать обычную формулу Пифагора для 3-х мерного пространства.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. В этом же окне присвоим таблице систему координат - установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. [http://gis-lab.info/forum/viewtopic.php?f=17&t=4708&hilit=+%D1%82%D0%BE%D1%87%D0%BD%D0%BE%D1%81%D1%82%D1%8C#p21658 Обсуждение проблемы смотрим вот здесь]
Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

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

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]

''Примечание: приведенная программа является собственной разработкой (с)2011. В новые версии мапинфо входит улучшенный аналог, который позволяет задавать построение множества геобъектов из наборов точек, в то время как эта программа создает единственный объект на основании входного списка. Более функциональные программы используют для определения порядка создания вершин два индекса - первый задает объекты, второй, порядок вершин в объекте. Приведенные в статье программа не использует индексов, а создает вершины в порядке том же порядке как они записаны в исходных файлах.
Кроме того возможно создание геообъектов через программы библиотеки GDAL/ORG, как это описано в статье ''[http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления в MapInfo производятся только по двумерным координатам при геообъекте, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T21:02:01Z

Boris: /* Порядок обработки данных */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 . ИСключения могут быть связаны только с форматом файла Excel, у котором созданы исходные данные.

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные, т.е. точки с отрицательной высторой над уровнем моря, отрицательными координатми или отрицательной скоростью:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести предварительный расчет в Excel. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

На основании выполненных вычислений мы получили пределы, в которые вписываются все координаты. Используя явное указание границ (см. ниже) при задании системы координат (проекции) таблицы Мапинфо, мы существенно повышаем точность измерения. Вычислив среднее значение "Координата_2", мы получили возможность выбрать центральный меридиан проекции "Поперечная Меркатора" (или проекция "Гаусса-Крюгера"). Это сделано для того, что бы уменьшить различие между спроецированными расстояними и расстояниями, вычисленными с учетом кривизны Земли, т.к. в дальнейшем при переходе от координат в градусах к координатам в метрах, для вычисления расстояний между точками мы будем использовать формулу Пифагора.

13. Откроем окно "Управление параметрами и полями таблицы" в Mapinfo - присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы координат, полученные в п.12, с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

22. В окне карты получится ужас, нам она нужна только как образец.

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]
Примечание: приведенная программа является собственной разработкой. В новые версии мапинфо входит улучшенный аналог, который позволяет управлять создаваемыми геобъектами, в то время как эта программа создает единственный объект на основании входного списка. Кроме того возможно создание гео-объектов через программы библиотеки GDAL/ORG, как это описанор в статье [http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-07-26T20:34:21Z

Boris: /* Порядок обработки данных */

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Описывается решение задачи перевода координат заданных в градусах в координаты в метрах. Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение ===
==== Постановка задачи ====
Имеется набор данных, состоящих из координат точек в формате долгота/широта/высота. К каждой точке также приписан набор атрибутов. В рассматриваемом случае атрибуты — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.

==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в Excel дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С последующей обработкой результатов в Excel.

Причина выбора этого ПО:
* Предпочтение автора статьи;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;

==== Основные приемы использованные в работе ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. Например, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.

=== Порядок обработки данных ===
1. Открываем таблицу Excel. Приводим ее к виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем, например D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]
Примечание: для обработки данных использована ГИС MapInfo версии 9.5, однако описанные алгоритмы работают в версиях от 7.8 . ИСключения могут быть связаны только с форматом файла Excel, у котором созданы исходные данные.
4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой MapInfo типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Выполним фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

Такие данные не позволили бы нам произвести предварительный расчет в Excel. Для этого создадим и выполним SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

8. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

9. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

10. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

11. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

12. В результат получим:

[[Файл:Bsf a001 13.gif|рис.10]]

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

13. Откроем окно MapBasic в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

14. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

15. В окне MapBasic должны появиться две команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''

16. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

17. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

18. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

19. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущают уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''

20. Пришло время пересчитать координаты точек. Но для этого надо установить прямоугольную систему координат. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты:

[[Файл:Bsf a001 21.gif|рис.16]]

21. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

22. В окне карты получится ужас, нам она нужна только как образец.

23. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''

24. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся программой перевода последовательности точек в полилинию (или полигон):

[[Файл:Bsf a001 50.gif|рис.15]]
Примечание: приведенная программа является собственной разработкой. В новые версии мапинфо входит улучшенный аналог, который позволяет управлять создаваемыми геобъектами, в то время как эта программа создает единственный объект на основании входного списка. Кроме того возможно создание гео-объектов через программы библиотеки GDAL/ORG, как это описанор в статье [http://gis-lab.info/qa/csv2shp.html Конвертация данных из CSV в SHP и обратно с OGR]
51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:29:10Z

Boris:

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo, и задача много раз в ней решалась;
* MapInfo хорошо умеет читать данные в формате Excel;
* MapInfo, за счет встроенного интерпретатора языка MapBasic, хорошо автоматизируется «на коленке», когда это необходимо для мелких задач;
* Excel идеально подходит для между строчных вычислений, что является трудноразрешимой проблемой для всего, что построено на плоских таблицах с независимыми строками;
* Кроме того описание «вступительной» части необходимой для второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:23:50Z

Boris:

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция созданная к обсуждению на форуме ветки «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). Приемы статьи могут быть использованы для пересчета координат между различными проекциями, если те могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:14:57Z

Boris:

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция к обсуждению «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.''}}

=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:14:34Z

Boris:

{{Статья|Черновик}}

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 Инструкция к обсуждению «MapInfo - перевод долготы/широты в метры»]

{{Аннотация|Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.}}

=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:07:57Z

Boris:

== MapInfo - перевод долготы/широты в метры ==

[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]

''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:06:19Z

Boris:

== MapInfo - перевод долготы/широты в метры ==
[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]
''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, то что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

===== ''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
'' =====

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T18:02:30Z

Boris:

== MapInfo - перевод долготы/широты в метры ==
[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]
''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию.

20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец :)

24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан '''''107.63''''';

:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);

:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;

:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;

:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;

:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

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

29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть.

37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''

43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.

44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:

a. ячейка J2 ‑ '''«0»'''

b. ячейка K2 – '''«0»'''

c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)

d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.

e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».

47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.

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

49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.

50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту '''''h''''' она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
''

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T17:54:15Z

Boris:

== MapInfo - перевод долготы/широты в метры ==
[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]
''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|806px|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.

11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

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

14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

[[Файл:Bsf a001 15.gif|рис.11]]

16. В окне MapBasic’а должны появиться две вот такие команды:

:''Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:''Create Map For D20120503 CoordSys Earth Projection 1, 104''
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:

:''Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)''

После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.

18. Теперь создадим точки на месте координат:

[[Файл:Bsf a001 18-1.gif|рис.12]]
[[Файл:Bsf a001 18-2.gif|рис.13]]
[[Файл:Bsf a001 18-3.gif|рис.14]]

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию
20. В результате получим вот такую карту:

[[Файл:Bsf a001 20.gif|рис.15]]

:''Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.''
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

[[Файл:Bsf a001 21.gif|рис.16]]

22. Выберем самую первую – UTM-1N:

[[Файл:Bsf a001 22.gif|рис.17]]

23. В окне карты получится ужас что, нам она нужна как образец:
24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0''
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
:''Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''

26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые ''«8, 104, "m",»'' (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):

:a. Затем задали – центральный меридиан 107.63;
:b. ''0'' (экватор) заменили на минимальную южную границу = ''51'' (градус северной широты);
:c. ''0.9996'' – стандартный масштабный коэффициент для проекции UTM заменили на ''1'', т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;
:d. Уменьшили ложное восточное смещение – заменили ''500000'' на ''250000'' (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;
:e. ''0'' – ложное смещение на север, оставили ''0'', т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;
:f. Задали границы карты - ''Bounds (0,0) (500000, 500000)''. Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.

27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

[[Файл:Bsf a001 27.gif|рис.15]]

28. Откроем таблицу в виде списка, что бы видеть результаты вычислений.
29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
:''Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)''
30. Пришло время вычислить координаты. Для этого используем команду:
:''Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)''
31. ''COL8'' и ''COL9'' – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.

32. Наша открытая списком таблица обновится и приобретет вот такой вид:

[[Файл:Bsf a001 32.gif|рис.15]]

33. Обязательно сохраним ее.

34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

[[Файл:Bsf a001 34.gif|рис.15]]

35. Выберем вот такие параметры экспорта:

[[Файл:Bsf a001 35.gif|рис.15]]

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть 
37. Откроем экспортированную таблицу:

[[Файл:Bsf a001 37.gif|рис.15]]

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
:''Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)''
39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

[[Файл:Bsf a001 39.gif|рис.15]]

''До момента создания пространственной привязки таблица не появляется в списке слоев.''

40. Создадим точки и в этой таблице, только изменим их форму и цвет:

[[Файл:Bsf a001 40.gif|рис.15]]

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

[[Файл:Bsf a001 41.gif|рис.15]]

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

[[Файл:Bsf a001 42.gif|рис.15]]

Видим, что оно составило 4 мм. Это плата за пересчет и округление.
''На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.''
43. Все. С MapInfo закончили. Надо возвращаться в Excel.
''Пункты с 37-го по 42-ой можно опустить.'' Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.
44. Открываем результат экспорта как текстовый файл в Excel.

[[Файл:Bsf a001 44-1.gif|рис.15]]
[[Файл:Bsf a001 44-2.gif|рис.15]]
[[Файл:Bsf a001 44-3.gif|рис.15]]

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

[[Файл:Bsf a001 45.gif|рис.15]]

46. Заполним ячейки в новых колонках формулой:
a. ячейка J2 ‑ '''«0»'''
b. ячейка K2 – '''«0»'''
c. В ячейке J3 напишем формулу - '''''«=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))»''''' (Теорема Пифагора для 3-х мерного пространства)
d. в ячейке K3 напишем '''«=K2+J3»''' - это суммарный путь, пройденный до этой точки.
e. Теперь «растянем» формулу из ячеек '''''J3:K3''''' на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».
47. Мы получили искомый результат :) Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.
48. Сохраним этот результат. Excel сообщит нам, что наш формат не поддерживает все возможности Excel, поэтому для последующее обработки надо сохранить данные в его формат.
49. Теперь, ''по уму'', надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.
50. Для этого воспользуемся специальной программой:

[[Файл:Bsf a001 50.gif|рис.15]]

51. Вот что получим, измерив длину новой линии:

[[Файл:Bsf a001 51-1.gif|рис.15]]

Или с учетом кривизны Земли:

[[Файл:Bsf a001 51-2.gif|рис.15]]

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту h она считать не умеет и для узлов не хранит. Результат вычислений в Exec = '''''226 781 m.'''''

53. Если я ничего не перепутал то, что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

[[Файл:Bsf a001 53.gif|рис.15]]

''Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции
''

Файл:Bsf a001 41.gif

2012-05-09T17:45:37Z

Boris:

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T17:30:19Z

Boris:

== MapInfo - перевод долготы/широты в метры ==
[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]
''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):

[[Файл:Bsf a001 03.gif|563px|рис.1]]

4. Используем заголовки для наименования столбцов:

[[Файл:Bsf a001 04.gif|рис.2]]

5. Подтвердим выбранные самой манифно типы данных:

[[Файл:Bsf a001 05.gif|рис.3]]

6. Откроем таблицу для просмотра в виде списка, т.к. пока у нас есть только атрибутика, но нет геометрии:

[[Файл:Bsf a001 06.gif|рис.4]]

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

[[Файл:Bsf a001 07.gif|рис.5]]

8. Именно это не позволило нам произвести пред расчет в Excel. Для этого создадим SQL запрос:

[[Файл:Bsf a001 08.gif|рис.6]]

9. Получим вот такой результат:

[[Файл:Bsf a001 09.gif|рис.7]]

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.
11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

[[Файл:Bsf a001 11.gif|рис.8]]

12. И сразу еще один запрос на данных предыдущего запроса:

[[Файл:Bsf a001 12.gif|рис.9]]

13. В результат получим что-то такое:

[[Файл:Bsf a001 13.gif|рис.10]]

''Все эти данные нам понадобятся, что бы создать геоинформацию к нашей Excel таблице.''
14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

16. В окне MapBasic’а должны появиться две вот такие команды:

:Alter Table "D20120503" ( add X Float,Y Float ) Interactive
:Create Map For D20120503 CoordSys Earth Projection 1, 104
:
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:
Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)
После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.
18. Теперь создадим точки на месте координат:

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию
20. В результате получим вот такую карту:

Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

22. Выберем самую первую – UTM-1N:

23. В окне карты получится ужас что, нам она нужна как образец:
24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)
26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые «8, 104, "m",» (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):
a. Затем задали – центральный меридиан 107.63;
b. 0 (экватор) заменили на минимальную южную границу = 51 (градус северной широты);
c. 0.9996 – стандартный масштабный коэффициент для проекции UTM заменили на 1, т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;
d. Уменьшили ложное восточное смещение – заменили 500000 на 250000 (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;
e. 0 – ложное смещение на север, оставили 0, т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;
f. Задали границы карты - Bounds (0,0) (500000, 500000). Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.
27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

28. Откроем таблицу в виде списка, что бы видеть результаты вычислений.
29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)
30. Пришло время вычислить координаты. Для этого используем команду:
Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)
31. COL8 и COL9 – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.
32. Наша открытая списком таблица обновится и приобретет вот такой вид:

33. Обязательно сохраним ее.
34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

35. Выберем вот такие параметры экспорта:

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть 
37. Откроем экспортированную таблицу:

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)
39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

До момента создания пространственной привязки таблица не появляется в списке слоев.
40. Создадим точки и в этой таблице, только изменим их форму и цвет:

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

Видим, что оно составило 4 мм. Это плата за пересчет и округление. На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.
43. Все. С MapInfo закончили. Надо возвращаться в Excel.Пункты с 37-го по 42-ой можно опустить. Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.
44. Открываем результат экспорта как текстовый файл в Excel.

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

46. Заполним ячейки в новых колонках формулой:
a. ячейка J2 ‑ «0»
b. ячейка K2 – «0»
c. В ячейке J3 напишем формулу - «=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))» (Теорема Пифагора для 3-х мерного пространства)
d. в ячейке K3 напишем «=K2+J3» - это суммарный путь, пройденный до этой точки.
e. Теперь «растянем» формулу из ячеек J3:K3 на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».
47. Мы получили искомый результат  Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.
48. Сохраним этот результат. Excel сообщит нам, что наш формат не поддерживает все возможности Excel, поэтому для последующее обработки надо сохранить данные в его формат.
49. Теперь, по уму, надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.
50. Для этого воспользуемся специальной программой:

51. Вот что получим, измерив длину новой линии:

Или с учетом кривизны Земли:

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту h она считать не умеет и для узлов не хранит. Результат вычислений в Exec = 226 781 m.
53. Если я ничего не перепутал то, что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции

Перевод долготы-широты в метры и подходы по работе в MapInfo

2012-05-09T17:14:36Z

Boris:

== MapInfo - перевод долготы/широты в метры ==
[http://gis-lab.info/forum/viewtopic.php?f=17&t=2036 MapInfo - перевод долготы/широты в метры]
''Эта статья посвящена задаче перевода координат заданных градусах в координаты в метра ( футах, дюймах и т. п.). С равным успехом основные приемы данной статьи могут быть использованы для перевода между различными системами координат, которые могут быть заданы стандартными средствами ГИС MapInfo.
''
=== Введение: ===
==== Постановка задачи: ====
Имеется набор данных, состоящих из координат точки в формате долгота/широта/высота. К каждой точке приписан набор непространственных атрибутов. В рассматриваемом в случае — время создания точки и некоторые специфические параметры, связанные с работой технического средства. Данные даны в виде плоской таблицы или в виде приводимом к плоской таблице. В нашем случае в формате Excel. Требуется произвести вычисления расстояния между соседними точками и сохранить результат так, что бы его можно было использовать в Excel.
==== Общее описание алгоритмов: ====
Для решения задачи можно использовать:
* Любую ГИС, позволяющую вычислять координаты точек в различных системах координат (или проекциях);
* Программные средства командной строки, позволяющие производить вычисления над плоскими файлами. На пример, утилиту командной строки ogr2ogr или иную, использующую библиотеку PROJ4, или ее аналог;
* Вставить в EXCEL дополнительные модули или формулы, которые позволят произвести вычисление координат, заданных в градусах, в координаты на плоскости в некоторой проекции. В принципе в тот же Excel можно вставить вызов библиотек PROJ4.

==== Почему MapInfo + Excel? : ====
В этой статье будет рассмотрен набор манипуляций с данными с использованием ГИС MapInfo. С пост обработкой результатов в Excel.
Причина такого выбора банальна:
* вопрос был задан в разделе про MapInfo;
* MapInfo хорошо умеет читать данные в формате Excel;
* Excel идеально подходит для между строчных вычислений, что является трудно проблемой для всего, что построено на принципах СУБД, как-то плоские таблицы с независимыми строками;
* Кроме того описание «вступительной» части второго и третьего варианта, есть задача, которая требует других знаний, чем у автора, и другого терпения. А рекомендовать проделать все это тем, кто не нашел сил, что бы выполнить «вступительную» часть для других задач, я не готов. Равно как не знаю есть ли смысл рассказывать такую банальность тем, кто это проделал. Есть подозрение, что они эту задачу решат и без меня. И мне бы еще у них поучиться жонглировать различными ГИС форматами в ogr2org. Хотя бы тем же CSV, который подходит для этих задач лучше много другого. Тем более, что и в этом случае остается задача рекурсивного доступа от точки к ее предшественнику, а это без простейшего программирования трудно реализовать.
==== Основные приемы использованные в работе: ====
#Главный прием — 95% процентов команд графического ядра ГИС MapInfo являются текстовыми командами на языке MapBasic. При стандартном выполнении через меню и «кнопки» эти команды формируются в GUI, выводятся в окно MapBasic в MapInfoи одновременно передаются на выполнение ядру ГИС MapInfo, которое можно считать интерпретатором команд MapBasic'а.
#Если выбрать соответствующую команду в окне MapBasic в MapInfo, выделив несколько строк подряд, или просто поместив курсор в конец одной строки, и нажать «Ввод» на клавиатуре, то выбранные команды будут переданы интерпретатору команд MapBasic и они дадут к такой же результат, что и вызов команд через графический интерфейс.
#Поэтому используя команды от стандартных элементов меню MapInfo, выводимые в MapBasic, как шаблоны для собственных команд, или используя любые команды и операторы языка MapBasic, за исключением операторов проверки условий (на пример, IF) или циклов (FOR или DO), можно получать большую гибкость при работе с данными в этой ГИС.
#За пределами этого рассмотрения остается возможность посылки аналогичных команд через OLE интерфейс MapInfo. В этом случае они выполняются так же, как если бы их вводили в окно MapBasic.
#Так же работа основана на том, что MapInfo хорошо читает многие стандартные форматы табличных данных, и в некоторые из них позволяет сохранять свои таблицы.
#В свою очередь Excel легко позволяет выписать функцию на рабочем листе, а потом применить ее к соседним клеткам с сохранением условной или безусловной адресации между ячейками. На пример, для того что бы формула, заданная в 3-м столбце строки, выполняющая расчет на основе первых двух ячеек строки, была аналогично использована в следующей строке, достаточно просто растянуть ячейку в 1:3 или С1 следующую ячейку снизу — 2:3 или С2.
=== Порядок обработки данных: ===
1. Открываем таблицу Excel. Приводим ее виду набора однородных данных – заголовки должны быть у всех столбцов, имеющих данные, и располагаться в первой строке. Столбцы без данных должны быть удалены.
2. Сохраним файл с простым именем D20120503.xls. С вот таким заголовком:
{| class="wikitable"
|-
! Время !! Высота над УМ !! Датчик скорости !! Координата-1 !! Координата-2 !! Обороты двигателя !! Конечная
|-
| 2012-05-03 07:31:40 || 521 || 18 || 51.822845 || 107.679138 || 1482 || мелькомбинат
|-
| 2012-05-03 07:32:27 || 525 || 22 || 51.81982 || 107.682434 || 1208.4 ||
|-
|}
3. Загрузим данные в MapInfo (галочку – создать копию ставим обязательно):
<gallery>
Bsf a001 03.gif|рис.1
</gallery>

4. Используем заголовки для наименования столбцов:

5. Подтвердим выбранные самой манифно типы данных:

6. Получим данные в виде таблицы, т.к. пока у нас есть только атрибутика, но нет геометрии:

7. Теперь надо выполнить фильтрацию данных, т.к. в некоторых строках есть некорректные данные:

8. Именно это не позволило нам произвести предрасчет в Excel. Для этого создадим SQL запрос:

9. Получим вот такой результат:

10. Удалим все сбойные строки нажав Del. После этого сохраним таблицу и упакуем ее.
11. Теперь вычислим несколько параметров наших данных. Опять же через SQL запрос:

12. И сразу еще один запрос на данных предыдущего запроса:

13. В результат получим что-то такое:

Все эти данные нам понадобятся, что бы создать геоинформацию к нашей Excel таблице.
14. Для этого откроем окно MapBasic’а в Mapinfo и присвоим таблице систему координат и добавим два поля для плановых (плоских, метровых ) координат – X,Y:

15. Установим проекцию «Долгота/Широта WGS84»:

16. В окне MapBasic’а должны появиться две вот такие команды:
Alter Table "D20120503" ( add X Float,Y Float ) Interactive
Create Map For D20120503 CoordSys Earth Projection 1, 104
17. Для нас важна вторая строка, которая и создает систему координат (СК) таблицы. Нас она не устраивает, т.к. создает СК, которая охватывает весь мир, что плохо для точности наших данных. Изменим строку команды, что она приобрела вот такой вид – добавим ей границы измерений с некоторым запасом:
Create Map For D20120503 CoordSys Earth Projection 1, 104 Bounds (107.5, 51.7) (107.8, 52)
После этого вставим эту строку в окно MapBasic’а, встанем на ее конец (или выделим ее целиком) и нажмем «Ввод». Дальше для любой строки команд, необходимость выделения вставленной команды и ее ввода будет подразумеваться.
18. Теперь создадим точки на месте координат:

19. Кнопку «Проекция» - не трогаем. Тогда проекция вычисления координат и проекция таблицы – совпадут по умолчанию
20. В результате получим вот такую карту:

Смущаю меня уходы в сторону, но это уже вопрос корректности данных. Будем надеяться, что там точки идут в обоих направлениях.
21. Пришло время пересчитать координаты точек. Но для этого надо установить плоскую проекцию. Сделаем это на примере проекции UTM. Причем опять с использованием шаблона из стандартных проекций, которые потом подправим «под себя». Для этого сделаем самое простое – установим проекцию окна карты :

22. Выберем самую первую – UTM-1N:

23. В окне карты получится ужас что, нам она нужна как образец:
24. В окне MapBasic’а будет выведена следующая команда, соответствующая установке для текущего окна карт выбранной нами проекции:
Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", -177, 0, 0.9996, 500000, 0
25. Заменим эту проекцию на нужную нам, взяв новый центральный меридиан из среднего значения координат таблицы (п.13):
Set Map XY Units "m" CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)
26. Обращаю внимание, что мы в параметрах проекции заменили их практически все – оставив только первые «8, 104, "m",» (что означает проекция «поперечная Меркатора», на датуме WGS84, единица измерения координат «метры»):
a. Затем задали – центральный меридиан 107.63;
b. 0 (экватор) заменили на минимальную южную границу = 51 (градус северной широты);
c. 0.9996 – стандартный масштабный коэффициент для проекции UTM заменили на 1, т.к. наши измерения предполагаются возле центрального меридиана (ЦМ) проекции, а стандартный масштабный коэффициент для UTM уменьшает расстояния возле ЦМ.;
d. Уменьшили ложное восточное смещение – заменили 500000 на 250000 (что то же для наших данных). Принципиального значения это не имеет. Могли и 0 поставить, округления во внутренних расчетах MapInfo для таких величин будут незначительны. Вот в случаях, когда используется проекция СК-42 или СК-95, то «добавочные» миллионы, задающие зону, могут оказать неприятное воздействие на MapInfo, да и на Excel - то же.;
e. 0 – ложное смещение на север, оставили 0, т.к. уже сдвинули начало системы координат задав смещение в п. 26.b;
f. Задали границы карты - Bounds (0,0) (500000, 500000). Это существенно для Mapinfo только при вычислении координат. Для окна карты не имеет никакого значения. Границы выставили из предположения, что все наши координаты впишутся в квадрат 500 на 500 км.
27. Проверим, что наши параметры вернули карте нормальный вид, такой как она имела изначально – дадим команду показать все слои карты в нашем окне:

28. Откроем таблицу в виде списка, что бы видеть результаты вычислений.
29. Теперь установим систему координат, которую MapInfo , будет использовать для расчета координат. Для этого введем следующую строку в окно MapBasic’а, используя ранее полученную строку как шаблон:
Set CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0, 0) (500000, 500000)
30. Пришло время вычислить координаты. Для этого используем команду:
Update D20120503 set col8=centroidx(obj),col9=centroidy(obj)
31. COL8 и COL9 – это псевдонимы для 8 и 9 колонки, соответственно. Вместо них обычно используют настоящие названия колонок, но так проще и короче.
32. Наша открытая списком таблица обновится и приобретет вот такой вид:

33. Обязательно сохраним ее.
34. Теперь нам надо вернуть данные в Excel. Проще всего это сделать, сохранив данные в тестовый формат, т.к. экспорта в Excel в MapInfo – нет. По крайней мере, в моей версии.

35. Выберем вот такие параметры экспорта:

36. Сознательно добавим букву «а» к имени, предложенному Mapinfo, т.к. ниже мы загрузим экспорт обратно, а если имя текстового файла совпадет с именем таблицы, MapInfo не даст нам ее открыть 
37. Откроем экспортированную таблицу:

38. Присвоим открытой таблице координатную систему для гео-объектов, используя полученные ранее команды как шаблон:
Create Map For D20120503a CoordSys Earth Projection 8, 104, "m", 107.63, 51, 1, 250000, 0 Bounds (0,0) (500000, 500000)
39. То, что это удалось можно увидеть, добавив новую таблицу в окно карты:

До момента создания пространственной привязки таблица не появляется в списке слоев.
40. Создадим точки и в этой таблице, только изменим их форму и цвет:

41. И естественно выберем новые расчетные столбцы в качестве координат создаваемых точек.
После нажатия на «OK» - окно карты измениться. В нем появятся новые геокодированные точки:

42. Максимально приблизим одну из точек, что бы стало заметно различие между старыми (фиолетовыми) и новыми (зелеными) точками:

Видим, что оно составило 4 мм. Это плата за пересчет и округление. На мой взгляд, в большей степени за округление, с которым Mapinfo вывел данные в текстовый файл – всего 2 символа после запятой (точки). Эту точность можно принудительно увеличивать с помощью функции Format$, но это в этом случае не играет большой роли.
43. Все. С MapInfo закончили. Надо возвращаться в Excel.Пункты с 37-го по 42-ой можно опустить. Они были необходимы только для проверки корректности выполненных нами манипуляций с координатными системами.
44. Открываем результат экспорта как текстовый файл в Excel.

45. Получим вот такую таблицу в Excel и добавим в нее две колонки «расстояние» (между соседними точками) и «путь» (сумму расстояний):

46. Заполним ячейки в новых колонках формулой:
a. ячейка J2 ‑ «0»
b. ячейка K2 – «0»
c. В ячейке J3 напишем формулу - «=КОРЕНЬ((H2-H3)*(H2-H3)+(I2-I3)*(I2-I3)+(B2-B3)*(B2-B3))» (Теорема Пифагора для 3-х мерного пространства)
d. в ячейке K3 напишем «=K2+J3» - это суммарный путь, пройденный до этой точки.
e. Теперь «растянем» формулу из ячеек J3:K3 на все оставшееся заполненное пространство листа Excel.
Существуют и более правильные способы задания формулы на столбцы, но они слегка длиннее и мудренее, чем просто «взять за угол и растянуть».
47. Мы получили искомый результат  Все строки содержат расстояние от точки до предшествующей ей, а так же пройденный путь.
48. Сохраним этот результат. Excel сообщит нам, что наш формат не поддерживает все возможности Excel, поэтому для последующее обработки надо сохранить данные в его формат.
49. Теперь, по уму, надо бы построить линию по этим точкам, что бы убедиться, что расстояние мы измерили без погрешности.
50. Для этого воспользуемся специальной программой:

51. Вот что получим, измерив длину новой линии:

Или с учетом кривизны Земли:

52. Тут надо помнить, что вычисления MapInfo провело только по двумерным координатам, высоту h она считать не умеет и для узлов не хранит. Результат вычислений в Exec = 226 781 m.
53. Если я ничего не перепутал то, что казалось набором последовательных точек, оказалось набором вершин от разных проходов по одному пути, пройденных в разное время:

Ключевые слова: MapInfo, MapBasic команды, Select SQL, долгота/широта, преобразование коррдинат, пользовательские проекции

Файл:Bsf a001 53.gif

2012-05-09T17:10:52Z

Boris:

Файл:Bsf a001 51-2.gif

2012-05-09T17:10:45Z

Boris:

Файл:Bsf a001 51-1.gif

2012-05-09T17:10:35Z

Boris:

Файл:Bsf a001 50.gif

2012-05-09T17:10:26Z

Boris:

Файл:Bsf a001 45.gif

2012-05-09T17:10:17Z

Boris:

Файл:Bsf a001 44-3.gif

2012-05-09T17:10:10Z

Boris:

Файл:Bsf a001 44-2.gif

2012-05-09T17:10:02Z

Boris:

Файл:Bsf a001 44-1.gif

2012-05-09T17:09:56Z

Boris:

Файл:Bsf a001 42.gif

2012-05-09T17:09:43Z

Boris:

Файл:Bsf a001 40.gif

2012-05-09T17:09:34Z

Boris:

Файл:Bsf a001 39.gif

2012-05-09T17:09:26Z

Boris: