| Повече ▼

Как да препроектирате всички геометрични колони в схема PostGIS

Как да препроектирате всички геометрични колони в схема PostGIS


Има ли начин да се репроектират всички геометрични колони на схема postgis, дадени един и същ SRID на източника към един и същ SRID на дестинация?
Пример:
schema.table1 има 2 геометрични колони geom и geom2 със същия SRID 900913
schema.table2 има 2 геометрични колони geom и geom2 със същия SRID 900913
и т.н. ...
Искам да прожектирам всички тези колони в SRID 2154. Помислих, че може да има прост начин, като използвам изгледа public.geometry_columns, но не знам как.


Можете да направите това с помощта на Postgres DO блок, по същество анонимна функция, която просто стартирате веднъж от psql подкана. Нещо в тази насока:

DO $$ декларира r запис; НАЧАЛО ЗА r в SELECT srid като srs, f_table_name като име, f_geometry_column като geom ОТ geometry_columns WHERE f_table_schema = 'schema_name' LOOP RAISE NOTICE 'актуализираща таблица:%, geom колона:%, с srid:%', r.name, r. geom, r.srs; ИЗПЪЛНЕТЕ UpdateGeometrySRID (r.name, r.geom, 2154); ИЗПЪЛНИТЕ ФОРМАТ ('АКТУАЛИЗИРАНЕ%, зададох% I = ST_Transform (% I, 2154)', r.name, r.geom, r.geom); END LOOP; END $$;

Това използва UpdateGeometrySRID за актуализиране на метаданните и ST_Transform за трансформиране на геометриите. Трябва да използватеИзпълнетев рамките на анонимен блок като този, тъй като не връщате нищо от select иизпълнете форматтъй като имате динамични имена на таблици.

Естествено, можете да добавите още къмКЪДЕТОклауза, тъй като може да не искате да изключите определени таблици и ще трябва да замените името на схемата с действителното име на схемата. Ясно е, че можете да поставите и това във функция, но звучи като еднократно упражнение.

Възможно е да има по-прост начин, за който аз не съм наясно.


Благодаря Джон, перфектно решение с леко актуализиране.

DO $$ Деклариране на r запис; НАЧАЛО ЗА r в SELECT srid като srs, f_table_name като име, f_geometry_column като geom FROM geometry_columns WHERE f_table_schema = 'Schema_name' LOOP RAISE NOTICE 'актуализираща таблица:%, geom колона:%, с srid:%', r.name, r. geom, r.srs; ИЗПЪЛНЕТЕ UpdateGeometrySRID (quote_ident (r.name), quote_ident (r.geom), 2154); ИЗПЪЛНИТЕ ФОРМАТ ('АКТУАЛИЗИРАНЕ%, зададох% I = ST_Transform (% I, 2154)', r.name, r.geom, r.geom); END LOOP; END $$;

Йерархични топогеометрии на топология PostGIS

I & # 8217m търся насоки как правилно да организирам йерархични топогеометрии.

Аз & # 8217m работя чрез PostGIS в действие & # 8217s глава за топологията и, в обобщение, създава две таблици с топогеометрии, едната наречена квартали (която става слой 1), която се основава на геометрии, заредени с toTopoGeom, и една, наречена градове (слой 2), който е получен от кварталите (слой 1).

Книгата казва това за слой 2.

& # 8220 & # 8230 След това определяте колона, наречена топо в таблицата градове, за да дефинирате кварталите, от които се състои всеки град. Всеки град се определя от топогеометрия. В примера искате само един град, така че & # 8217s има само една топогеометрия & # 8221

Намирам това за объркващо. Мислех, че дефиницията на колоната е топогеометрията, в който случай как всеки ред (град) може да има различен?

Какво да кажа, че искам повече от един град? Къде отиват кварталите. Как да кажа, че & # 8216 този град има тези квартали от слой 1, а този втори град има тези различни квартали от слой 1 & # 8217?

Аз & # 8217m явно пропускам нещо важно, защото в момента ми се струва, че всеки & # 8216parent & # 8217 в йерархията в крайна сметка завършва като единичен единичен ред в таблица.

Един отговор

Нямам достъп до пълния пример, за който говорите, но мисля, че грешно четете. В последното изречение авторът говори за вмъкване на редове, а не за добавяне на колони.

Бих го преформулирал по следния начин:

& quot. След това определяте a йерархична топогеометрия колона, наречена топо в таблицата градове, за да се дефинира квартали топогеометрии че всеки град е съставен от.

Всеки град се определя от ред в таблицата с градове, състоящ се от атрибути som и a стойност на топогеометрията.

В примера искате само един град, така че ще вмъкнете в таблицата с градове a единичен ред с топогеометрия, съставена от всички съседни топогеометрии& quot

Добавянето на град би било като:

Явно пропускам нещо важно, защото в момента ми се струва, че всеки „родител“ в йерархията в крайна сметка завършва като единичен единичен ред в таблица.

Наистина е така, всеки град ще съответства на ред и неговата колона с топогеометрия ще съхранява справка за всяко дете, от което се състои. Можете да мислите за детските топогеоми като за някакви междинни примитиви.

По този начин промените в детска топогеометрия ще бъдат автоматично отразени в родителските.


1 отговор 1

Това е стратегията за архивиране, която най-накрая приложих:

1. Нормално изхвърляне на базата данни PostGIS-Postgres с pg_dump. Формат на обикновен текст за подобряване на четливостта.

2. CSV архивиране на всички таблици

За това създадох копие на първоначалната си база данни ("la_as_text") и трансформирах всички геометрични колони в текст със следния скрипт (благодаря @Jim Jones). Това е много специфично за моя случай, но все пак реших да го публикувам така. Само в случай, че някой работи в предстоящите проблеми, както направих с изгледите, които зависят от геометричните колони и индексите. Изгледите няма да работят, ако промените типа данни на текст и текстовите колони също не са валидни за индексиране на gist.

Получената база данни липсва много от първоначалната си функционалност поради липсващия тип данни за геометрия, но е четима от човека.

Вместо нормален дъмп, експортирах всички отделни таблици като текстови файлове, разделени с '' със следния скрипт:

Доста съм уверен, че този архив може да бъде възстановен в бъдеще - ако е необходимо.


Хибернация 5.1 с картографиране на геометрични колони Postgis 2.2

Документацията за hibernate 5.1 spatial все още не е пусната (AFAIK) и се опитвам да продължа обектите с JST геометрични полета към PostgreSQL 9.5 + Postgis 2.2, без никакъв късмет.

Също така забелязах, че в hibernate-core-5.1.0 няма пакет org.hibernate.spatial. Опитах варианти на следната анотация:

Когато columnDefinition е зададено на "Point", получавам "колона" the_geom "е от тип point, но изразът е от тип bytea". В документацията за пространствен 4 на хибернация се казва, че анотацията @Type няма да е необходима от версии 5+, но какво трябва да се използва вместо това? Как да съхранявате geom като валидна геометрия на Postgis?


1 отговор 1

Успях да постигна неоптимално решение с помощта на Крейг и Александрос в горните коментари.

Идентифицирайте кои полигони са деца и ги маркирайте като такива:

АКТУАЛИЗИРАНЕ на зони SET родител = b.id ОТ зони b КЪДЕ ST_Contens (b.geom, a.geom) И a.id! = B.id

Изпълнете две заявки в TileMill както за родителска, така и за детска геометрия

Родители: (ИЗБЕРЕТЕ * от зони, КЪДЕТО родителят е НУЛ)
Деца: (SELECT * от зони, КЪДЕто родителят НЕ Е НУЛЕН)

Приложете комп-опция само към родителския слой и се уверете, че детският геометричен слой е „над“ родителския в списъка със слоеве, така че да е нарисуван отгоре.

За съжаление, това все още не е перфектно. Детските геометрии все още не могат да имат стойност на непрозрачност, в противен случай родителският цвят ще се смеси и ще доведе до приемането на друг цвят.


GeoManager ¶

За да се извършват географски запитвания, всеки географски модел изисква мениджър на модели GeoManager. Този мениджър позволява правилното изграждане на SQL за географски заявки, така че без него всички географски филтри ще се провалят. Трябва също така да се отбележи, че GeoManager се изисква, дори ако моделът сам по себе си няма географско поле, например в случай на връзка на ForeignKey с модел с географско поле. Например, ако имахме модел на адрес с чужд ключ към нашия модел на пощенски код:

Географският мениджър е необходим за извършване на пространствени заявки за свързани пощенски обекти, например:


Активиране и премахване на поддръжка на PostGIS

Активиране на поддръжката на PostGIS

За да активирате поддръжката на PostGIS, инсталирайте пакета за разширение Greenplum PostGIS в системата на базата данни Greenplum и след това използвайте командата CREATE EXTENSION, за да активирате поддръжката на PostGIS за отделна база данни.

Инсталиране на пакета за разширение Greenplum PostGIS

След като инсталирате пакета, изтеглете файла greenplum_path.sh и рестартирайте базата данни Greenplum. Тази команда рестартира базата данни Greenplum.

Инсталирането на пакета за разширение Greenplum PostGIS актуализира системата на базата данни Greenplum, включително инсталиране на поддържаните разширения PostGIS в системата и актуализиране на файла greenplum_path.sh с тези редове за поддръжка на PostGIS Raster.

Използване на командата CREATE EXTENSION

Тези стъпки позволяват разширението PostGIS и разширенията, които се използват с PostGIS.

    За да активирате PostGIS и PostGIS Raster в база данни, изпълнете тази команда, след като влезете в базата данни.

За да активирате PostGIS и PostGIS Raster в определена схема, създайте схемата, задайте search_path към PostGIS схема и след това активирайте разширението postgis с клаузата WITH SCHEMA.

След като активирате разширението, нулирайте search_path и включете PostGIS схемата в search_path, ако е необходимо.

За да активирате геокодера PostGIS TIGER, трябва да активирате разширението fuzzystrmatch, преди да активирате postgis_tiger_geocoder. Тези две команди позволяват разширенията.

Активиране на GDAL растерни драйвери

PostGIS използва GDAL растерни драйвери, когато обработва растерни данни с команди като ST_AsJPEG (). По подразбиране PostGIS деактивира всички растерни драйвери. Активирате растерни драйвери, като зададете стойността на променливата на околната среда POSTGIS_GDAL_ENABLED_DRIVERS във файла greenplum_path.sh на всички хостове на базата данни на Greenplum.

За да видите списъка на поддържаните GDAL растерни драйвери за система на базата данни Greenplum, стартирайте помощната програма raster2pgsql с опцията -G на главната база данни на Greenplum.

Командата изброява името на дългия формат на драйвера. Растерната таблица на GDAL на адрес https://gdal.org/drivers/raster/index.html изброява имената на дългия формат и съответните кодове, които посочвате като стойността на променливата на средата. Например кодът за дълго име Portable Network Graphics е PNG. Тази примерна линия за експортиране позволява четири GDAL растерни драйвера.

Командата gpstop -r рестартира системата на базата данни Greenplum, за да използва актуализираните настройки във файла greenplum_path.sh.

След като актуализирате файла greenplum_path.sh на всички хостове и рестартирате системата на базата данни Greenplum, можете да покажете активираните растерни драйвери с функцията ST_GDALDrivers (). Тази команда SELECT изброява активираните растерни драйвери.

Активиране на растри извън базата данни

След инсталирането на PostGIS, настройката по подразбиране POSTGIS_ENABLE_OUTDB_RASTERS = 0 във файла greenplum_path.sh деактивира поддръжката на растри извън базата данни. За да активирате тази функция, можете да зададете стойността на true (ненулева стойност) на всички хостове и да рестартирате системата на базата данни Greenplum.

Можете също да активирате или деактивирате тази функция за сесия на базата данни Greenplum. Например, тази команда SET активира функцията за текущата сесия.

Премахване на поддръжката на PostGIS

Използвате командата DROP EXTENSION, за да премахнете поддръжката за разширението PostGIS и разширенията, които се използват с PostGIS.

Премахването на поддръжката на PostGIS от база данни не премахва тези променливи на околната среда PostGIS Raster от файла greenplum_path.sh: GDAL_DATA, POSTGIS_ENABLE_OUTDB_RASTERS, POSTGIS_GDAL_ENABLED_DRIVERS. Променливите на средата се премахват, когато деинсталирате пакета за разширение PostGIS.

Използване на командата DROP EXTENSION

В зависимост от разширенията, които сте активирали за PostGIS, откажете поддръжката за разширенията в базата данни.

  1. Ако сте активирали таблицата за стандартизиране на адреси и примерни таблици, тези команди изпускат поддръжка за тези разширения от текущата база данни.
  2. Ако сте активирали геокодера TIGER и разширението fuzzystrmatch, за да използвате геокодера TIGER, тези команди отказват подкрепа за тези разширения.
  3. Прекъснете поддръжката за PostGIS и PostGIS Raster. Тази команда отпада поддръжката за тези разширения.

Ако сте активирали поддръжка за PostGIS и сте задали конкретна схема с командата CREATE EXTENSION, можете да актуализирате пътя на търсене и да пуснете схемата PostGIS, ако е необходимо.

Деинсталиране на пакета за разширение Greenplum PostGIS

След премахване на пакета се уверете, че тези редове за поддръжка на PostGIS Raster са премахнати от файла greenplum_path.sh.

Източник на файла greenplum_path.sh и рестартирайте базата данни Greenplum. Тази команда рестартира базата данни Greenplum.


5 отговора 5

От една страна, както е „предсказано“ във въпрос, някои коментари (тук и тук) и отговорът на JGH цитират примери за теми, които биха били само по темата за PostgreSQL. Мисля, че това е справедливо.

От друга страна, все още е малко объркване как се използват маркерите postgis и postgresql в GIS SE, особено въпроси, маркирани само postgresql (тъй като те също са свързани с PostGIS, търсенето става по-трудно и води до дублирания).

Затова моето предложение е (вижте „защо“ след него):

  1. Създайте „композитен маркер“ postgresql-postgis.
  2. Напишете откъс към него с обяснение какво е и как да го използвате. Стартирайте предложение:

Използвайте този маркер за ГИС ВЪПРОСИ за PostgreSQL И / ИЛИ PostGIS. PostgreSQL е обектно-релационна система от бази данни с отворен код. PostGIS е разширение за PostgreSQL, което добавя поддръжка за географски обекти.

Можем да използваме wiki на етикета, за да предоставим повече насоки за това, когато питаме в Stack Overflow SE или Database Administrators SE.

Мисля, че ако не беше PostGIS, много потребители все още биха използвали други системи за бази данни като MSSQL, MySQL и т.н., въпреки че PostgreSQL сам по себе си е страхотен. Мисля, че повечето хора (особено в тази общност) са съгласни, че един от най-важните му разлики е PostGIS.

Въпреки че те са различни продукти, на практика те не са (в смисъл „трябва да се използват заедно“ за целите на ГИС), така че много хора все още се объркват кое е едно и кое е друго.


Оптимизиране на съхранението PostGIS геометрии

Работите ли с пространствени данни, които покриват земното кълбо с нанометрова точност? Ако не, PostGIS вероятно губи място, когато съхранява вашата геометрия. Тази публикация описва техника, която може да се използва за намаляване на пространството за съхранение на геометриите на PostGIS във всички тези случаи, когато не работите с нанометри.

Кратък фон: PostGIS съхранява всички координати като стойности с двойна точност с плаваща запетая. Числото с двойна точност може точно да представлява приблизително 15 значими цифри. В много приложения PostGIS се използва с данни, които са точни с точност до стотна или хилядна от градуса (например -173,2243). Тъй като географската дължина варира от -180 до 180, съхраняването на тези данни изисква най-много седем значими цифри. Някои известни набори от данни (например TIGER) използват шест цифри след десетичната запетая, изисквайки девет значими цифри в WGS84. Във всички тези случаи голяма част от дисковото пространство, заето от геометрия, представлява шум.

В миналото спестявах място, като прибягвах до трикове като съхраняване на точки като в x / y колони, използвайки реалния тип данни и след това създавайки функционален индекс на ST_MakePoint (x, y). Това е грозно, работи само за обекти Point и създава сложност, която се влива във всяка заявка, която трябва да използва тези данни.

Оказва се, че можем да се възползваме от компресията, която е вградена в Postgres, за да си върнем голяма част от пространството, загубено от PostGIS. Просто трябва да модифицираме данните си, за да бъдат по-свиваеми.

Помислете за координатна стойност от набор от данни като TIGER, който представлява географски координати в микроградуси (приблизително 10 см прецизност): 44.455725. (Може да разпознаете това като географската ширина на най-високия шкаф в света.)

В двоична форма стойността на географската ширина изглежда така:

Символите във втория ред означават:

Тъй като нашата координата е само с микроградусна точност, не ни интересува дали тя се съхранява вътрешно като 44.45572531822 или 44.45572560712. С други думи, не са ни необходими всичките 52 бита, за да съхраняваме смислената част от нашата координатна мантиса.

Ако направите експеримент с printf в C, можете да видите, че нашата стойност на мантиса винаги е 44455725., независимо от това, което се намира в последните 29 бита. Тогава голяма част от нашето пространство просто съхранява шум:

Проблемът е не само в това, че ценните ни данни заемат точно толкова място, колкото и шума ни, но и това изглежда нашият шум има същото информационно съдържание като нашите ценни данни. Ако намалим видимото информационно съдържание от нашия шум, можем да го направим по-свиваемо. (Да, тук злоупотребявам с всякакъв вид терминология на CS.)

Тъй като установихме, че можем да настроим нашите шумни битове на каквото ни харесва, без да променяме микроградусната стойност на нашата координата, нека просто ги направим нула:

По този начин не сме загубили ценни данни. Не сме спестили място, но чрез намаляване на случайността сме направили номера си много по-свиваем. Тъй като Postgres автоматично компресира геометриите на PostGIS, хармонизирането на нашите битове на шума до нула или един трябва да намали размера на диска на геометричните обекти на PostGIS.

За да тествам практическите последици от това, написах малко изпълнение за почистване на PostGIS. Кодът е в клон на GitHub, но ядрото му е доста кратко:

Това се излага на ниво SQL по следния начин:

За да тествам ефективността, създадох таблица с около 100 MB кръгове:

Ами ако се нуждаем само от девет значими цифри в нашите кръгове?

Намаление от 23%. Не е лошо, но не е твърде вълнуващо. Какво ще кажете за шест цифри?

Повече от 50% - приятно! Струва си да се отбележи, че намаляването на размера не е толкова добро, колкото това, което получаваме от TWKB:

Въпреки това, хубавото на този трик е, че той разчита изцяло на вградената компресия Postgres. Не се изисква използването на друг тип данни и функциите, използващи вашите геометрии, не трябва да се интересуват, че сте извършили тази оптимизация.


PostGIS: заявка за пространствени данни

Флагът "-I" създава автоматично GiST индекс (обобщено дърво за търсене) в геометричната колона, което значително подобрява ефективността на пространствените заявки, тъй като, използвайки ограничителни кутии, позволява да се ограничи търсенето до подмножество, вместо на всички записи. Вместо v.in.ogr не създава пространствен индекс. Флагът "-s" и относителният код свързват правилната референтна система (тази на набора от данни в Северна Каролина) към улици шейпфайл. улици2postgis е името на новата таблица, улици.скл е името на текстовия файл, в който се записват SQL-изразите. Следващата стъпка е да изпълните тези изрази, зареждайки таблицата в базата данни:

psql -d gisdemo_ncpg -U трева -f улици.sql

Поглеждайки към масата geometry_columns можете да забележите, че колоните имат различни имена според командата, използвана за създаване на таблицата: "the_geom" за товарача, "wkb_geometry" за OGR. Сега повторете операцията с вектора геология map, като обърнете внимание, че този път имате работа с многоъгълна геометрия за вашия шейпфайл (тип опция = линия, граница, площ), затова използвайте -стр флаг, за да експортирате линиите като граници и да изберете само геометриите с категория (-° С флаг)


Гледай видеото: تبسيط استلام مخططات حديد السقف وشرح رموز المخطط