Форумы GIS-Lab.info

День добрый! Имеется архив КС с разных спутниковых систем (WorldView.tab, Pleiades.tab, Landsat.tab и т.д) одинаковой структуры (год, дата_съемки, спутник, Номер_снимка, разрешение, облачность, Оригеналы_GeoTiff,
Neris_sti, MapInfo, Квиклуки (с геолинком) и т.д. все поля символьные кроме дата_съемки).
Задача состоит в выборе, из всех имеющихся таблиц, КС за определенный год (допустим 2006 г.) с определенным набором колонок (например дата_съемки, спутник, Квиклуки). При работе с одной таблицей проблем не возникает с двумя и более затык (пробовал SQL-запрос, окно MapBasica - на уровне чайника т.к. языком программирования не владею), а хотелось бы получить именно выборку по всем спутникам в одной временной таблице. Насколько понимаю, структура запроса - это объединение всех таблиц и селекция по колонке "год", только как это воплотить не знаю. Подскажите, помогите составить запрос на выборку если это возможно. Такая выборка не устраивает
"Select * from Pleiades, WorldView, QuickBird where Pleiades.Год = WorldView.Год and WorldView.Год = QuickBird.Год and QuickBird.Год = "2012" into Selection" добовляются колонки. Нужно чтобы строки.

Выборку с объединение таблиц по некоторому полю обычно используют для таблиц связанных по общему полю (базовая и подчиненная таблицы). Здесь же возможно только объединить все таблицы в одну (Таблица/Добавить записи в таблицу…) и уже из нее формировать выборку. Или написать программу, которая все это будет делать, не организуя общую таблицу в явном виде.

Понятно. Т.е. получается опять все вручную. Создаю новую таблицу (напримкр All) такой же структуры и тупо добовляю записи в таблицу All из оригиналов (например в окне VapBasic:
insert into All (*, Спутник) SELECT *, Спутник from Pleiades
insert into All (*, Спутник) SELECT *, Спутник from WorldView
insert into All (*, Спутник) SELECT *, Спутник from QuickBird) далее сохраняю таблицу All или не сохраняю.
Провожу выборку по таблице All. Для меня это понятно, а вот для простых пользователей архива хотелось бы автоматезировать данный процесс в один-два клика, да и не хотелось бы создавать дополнительную физическую таблицу All.

1. Почему не используем БД?
Там есть такие вещи, как Представления (View) и временные таблицы, за одно и многопользовательский доступ легко организовать
2. Почему, в принципе, если структура у таблиц одинаковая, не о объединить их в одну, добавив поле Source и писать туда - источник снимка?

Совсем не обязательно писать запросы в окне MB, достаточно штатных функций MI:
1. Имеются таблицы тб1, тб2, тб3,…
2. Формируем копию тб1 с именем All (Файл/Сохранить копию…)
3. Пополняем All таблицами тб2, тб3,… через Таблица/Добавить записи в таблицу…
Как понимаю, поле Спутник является ссылкой на конкретную таблицу, и вносить дополнительной информации не потребуется.
Если вы заботитесь о «простых пользователях» почему бы не написать программу, облегчающую им жизнь. Это не так сложно.

1. БД организована в MI, простой смертный конвертировать-соеденять-объеденять таблицы не будет, конечный результат - ввел "2013" - "Ок" - "Визуализация Результата".
2. Объединять все таблицы в одну, как бы представляется лишним, на одну и ту же территорию имеются снимки с разных КС, где разная площадь покрытия, а значит разноразмерные полигоны (рис.1), т.е. насколько знаю большой полигон может перекрыть маленький. По этому отдельными таблицами оперировать намного удобнее, могу положить слой выше или ниже и в любой момент могу выключить визуализацию любого слоя (например слой Landsat, Spot и т.д.)

3. В идеале - создать кнопочку-пиктограмму (условно, "выбор фильтра" и по-максимому - не по одному параметру) в строке прочих пиктограмм, дабы любой "чайный" user нажал на нее, выбрал нужные фильтры и получил то, что хотел, он заморачиваться с SQL и прочими запросами не будет, да и лень ему больше 3 клавиш жать.

1. tab'ы это не БД. Я говорю о PostGIS, MS SQL Server, MySQL
2. К одной таблице можно подключится несколько раз с разными настройками фильтрации, в том числе по полю Source
3. Есть много способов создания GUI для БД...

Итак, всем здрасте.
Присоединюсь к теме моего коллеги. Работаем вместе, топик писался сообща, но взгляды наши чуть-чуть различны. Суть не в этом. Вот мой вариант поста.

Уважаемые "члены клуба любителей MapBasic", есть проблема.
Я в этот клуб не вхож (мы тут всё больше по экологии ), потому обращаюсь за помощью к вам.

Исходные данные:
MapInfo Proff 10.5 ru
Windows XP SP3
MapBasic 8.0 ru, MapBasic 10.5 eng

Объясню суть.
1. В рабочем наборе имеется N-ое количество однотипных по структуре таблиц (где N - количество от 3 до 10)
Для примера и отработки методики созданы таблицы: one.tab, two.tab, tree.tab
2. Структура таблиц ПОЛНОСТЬЮ идентична, т.е. совпадает вплоть до размера символьных полей.
Для примера - структура таблиц:
id - символьное (обозначает "год съемки")
Описание - символьное, поле геолинка, указывающее на растр.
Как Вы понимаете, таких растров может быть много, друг-друга могут перекрывать, да и MI со всеми ними еле ворочается/умирает. Т.е. изначально в рабочем наборе сами растры НЕ открыты, а могут быть открыты необходимые из них в результате запроса.
3. По условию задачи при сохранении на диске таблицы (one two tree) в принципе НЕ МОГУТ быть объединены в одну.
4. Стоит следующая задача: По запросу выделить во всех таблицах объекты, удовлетворяющие условию (например, год съемки - id)
5. По результату запроса сформировать временную таблицу (например, common.tab), где, естесствено, будут объекты, удовлетворяющие вышезаданному условию ("год съемки = 2014"). Таблица common является временной, на диске может и не сохраняться, только на время сеанса. Таблица common видна в списке слоёв, но не активна, дабы не мешать дальнейшей работе. (Последнее, впрочем, не проблема сделать и ручками)
6. Ну, а дальше все просто: открываем по geolink'ам необходимые объекты из "первичных" таблиц (которых N-ое количество - см. выше), т.е. открываем не все растры, а только те, что нужны. Решаем проблему с загрузкой памяти, MI - живёт

Видимые пути реализации:
1. Пробовали сию процедуру осуществить посредством SQL-запросов - не прокатывает. (ИМХО, в силу нехватки знаний, ну или ветра с Севера... )
2. Есть возможность "слияния" таблиц по-одиночке (создали таблицу common.tab и туда сливаем все N таблиц).
В окне MapBasic'а: (для таблицы one -> common)

Create Object As Union From one Into Table common Group by id Data id=id,Описание=Описание

Вариант на "айс", слишком много ручных операций, для специалиста может и подойдет, но муторно и долго с учётом не одного запроса, а нескольких. Для конечного пользователя - однозначно нет.

3. Пробовали через операцию "Добавить записи в таблицу"
В окне MapBasic'а: (для таблицы tree -> common)

Insert Into common ( COL1, COL2) Select COL1, COL2 From three

Та же "ручная" проблема.

Думается, что вариант решения лежит где-то в развитии пути №2, т.е. составлении некой программки на MB,
автоматизирующей все операции и с передачей необходимого параметра запроса (например, год съёмки - в данном примере - поле id)

Возможно выделение таблиц для запроса в "списке открытых таблиц".

Возможно выделение "первичных" таблиц в окне "управления слоями". Но здесь следующая "засада": у КАЖДОЙ из первичных таблиц существует тематика, т.е. количество слоёв в окне "управления слоями" возросло как минимум в 2 раза.

Естественно, сами исходные таблицы (которые типа one-two-tree) содержат не 2 поля (там их всего 14 - в основном, символьные, и поле Дата_съемки), но, ИМХО, суть от этого не меняется.

Кстати, пока писал вопрос, родилась ещё одна мысль.
Сделать временную таблицу (в данном случае - common) при открытии набора. Т.е. слить в нее (пока пустую) все открываемые "первичные" таблицы. Естессно, такая временная таблица в конце сеанса не сохраняется. "Засада": в наборе открываются и другие таблицы, не участвующие в запросе/выборке и имеющие другую структуру (например, дорожная сеть, гидрография и т.д. и т.п.). Соответсвенно, эта временная таблица должна быть сформирована ТОЛЬКО из этих "первичных" (которые могут открываться в наборе первыми, до открытия остальных). Ну вот как-то так... Вариант вроде как реализовали тупым слиянием таблиц 1-3 в common еще до открытия в карте, но в самом рабочем наборе такая структура не сохраняется. Да и по отсутствию какого-либо внятного интерфейса - НЕ ПОДХОДИТ.

Самый "айшный" вариант с MBX-прожкой. Нам он нравится больше. Тем более, есть перспектива развития соответствующего интерфейса с выбором запросов по разным полям...

Ну вот, в принципе и всё. Кто поможет - тому ВЕЧНЫЙ РЕСПЕКТ И УВАЖУХА!!!
Да, и очень бы хотелось иметь исходник на MB, уж его от-mbx-овать мы как-нибудь сможем...

P.S. Не пинайте за столь пространную "речь", я понимаю, что надо приступать к изучению MB, но (см. выше) "мы тут всё больше по экологии"... да и старый я уже...

P.P.S. Варианты с БД (MS SQL, MS Access, Oracle и т.д.) могут быть рассмотрены, но НАМНОГО позже. В данный момент - есть конкретная маленькая такая задачка, ИМХО, которую вполне решить средствами MapBasic'а. Да и в целях ликвидации нашей mapвасиковой безграммотности...

trir
Все tab-файлы в проекте MI это такая же реляционная база данных, как и другие. А сама программа MI имеет встроенную СУБД (система управления базой данных), конечно со своими особенностями.
Язык запросов практически во всех СУБД (реляционных) базируется на стандартном SQL со своими ограничениями и расширениями. Для задачи предложенной PVTs я не нашел решения в рамках одного запроса. Скорее получается сложный запрос с рядом подзапросов или, по сути, программа, но в терминах SQL. М.б. вы предложите решение в виде конкретного запроса, например для mySQL.
PVTs
Предлагаю вариант программы для решения вашей задачи(http://dfiles.ru/files/m6yctcm3b).

Перекомпилированный вариант программы для более ранних версий MI (http://dfiles.ru/files/rrtqq80nw). Обратите внимание тип поля, по которому определяется год, Date.

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

Добавил масштабирование карты по слою myQuery.

Thegeo
Огромное Спасибо. Опробовали работу программы с N количеством таблиц, работает на 5 баллов
(масштабирование карты по слою myQuery, выборка по годам, информация в выбранных колонках,
по крайней мере, меня устраивает на 100%). Практически задача выполнена. По этому, как говориться, аппетит приходит во время еды. Имеются идейки которые хотелось бы воплотить в жизнь на платформе вашей программы и мы были бы премного благодарны Вам за исходник на MB (вы являетесь автором и законным правообладателем и поэтому мы будем не против если перед запуском программы будет появляться ваша заставка), как писал мой коллега Старый Йети

Ну вот, в принципе и всё. Кто поможет - тому ВЕЧНЫЙ РЕСПЕКТ И УВАЖУХА!!!
Да, и очень бы хотелось иметь исходник на MB, уж его от-mbx-овать мы как-нибудь сможем...

C уважением PVTs

Выкладываю код. Комментариев нет т.к. не предполагал его передавать, а вставлять их задним числом не хочется. Будут вопросы задавайте. Думаю, что эти частности можно перенести в почту ибо не всем это интересно (адрес в ЛС).