[gdal-dev] New behaviour of "PROMOTE_TO_MULTI" ?

[Bo Victor Thomsen]

Thanks to Hugues and Richard for responding to my questions.

However, I'm using the ogr2ogr inside a DOS .cmd file like this:

for /R D:\tmp %%f in (*.tab) do ogr2ogr --config PG_USE_COPY yes 
-progress -lco OVERWRITE=YES -lco SCHEMA=mat -dim XY -a_srs EPSG:25832 
-f "PostgreSQL" PG:"host=localhost port=5432 user=*** password=*** 
dbname=geodata" "%%f"

I.e. iterating through a directory plus sub-directories and converting 
every found tab file into a table into schema "mat" using ogr2ogr

The tab files contains either points, linestrings or polygons. Polygons 
and linestrings can be a mix of simple and multi-objects. Each tab-file 
contains only one main type.

So I can't use "-nlt multipolygons". And the point of this project was 
to get rid of a fairly complex postgres based function that checks an 
uploaded table and change its geometry type using "alter table ... using 
st_multi(geom)" type of commands.

That was why I tried to use "-nlt promote_to_multi". According to this 
mail:

https://lists.osgeo.org/pipermail/gdal-dev/2012-September/034128.html

Even Rouault describes the exact behaviour I'm looking for: Simple 
linestrings / polygons will be changed to multi types and points will be 
left alone. And the geometry type will be set to a "multi*" as needed.

What actually happens is that linestrings, polygons /and/ points all are 
changed to multi type, but the geometry type remains "Geometry".


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 25-07-2022 kl. 15:52 skrev Hugues François:
> Hi,
>
> I guess you should either
> => drop the created table prior to launch the ogr2ogr command with the 
> -nlt PROMOTE_TO_MULTI switch
> => or maually alter the existing table: ALTER TABLE schema.table ALTER 
> COLUMN geom TYPE geometry(MultiPolygon, SRID) using ST_MULTI(geom)
>
> HTH,
> Hug
>
>
> ------------------------------------------------------------------------
> *De: *"Richard Greenwood" <richard.greenwood at gmail.com>
> *À: *"Bo Victor Thomsen" <bo.victor.thomsen at gmail.com>
> *Cc: *"gdal dev" <gdal-dev at lists.osgeo.org>
> *Envoyé: *Lundi 25 Juillet 2022 15:32:35
> *Objet: *Re: [gdal-dev] New behaviour of "PROMOTE_TO_MULTI" ?
>
> Have you tried -nlt MultiPolygon?
>
> On Mon, Jul 25, 2022 at 2:54 AM Bo Victor Thomsen 
> <bo.victor.thomsen at gmail.com> wrote:
>
>     I have a MapInfo .tab file containing polygons, both simple and
>     multipolygons (and only polygons).
>
>     Using this command: (all ogr2ogr commands are one-liners, but
>     examples are split for lucidity)
>
>     ogr2ogr
>       --config PG_USE_COPY yes
>       -progress
>       -lco OVERWRITE=YES
>       -dim XY
>       -f "PostgreSQL" PG:"host=localhost port=5432 user=***
>     password=*** dbname=geodata"
>       FREDSKOV.TAB
>
>     will (correctly) create a table in Postgres of PostGIS type
>     "Geometry"
>
>     If I change the command to:
>
>     ogr2ogr
>       --config PG_USE_COPY yes
>       -progress
>       -lco OVERWRITE=YES
>       -dim XY
>     *  -nlt PROMOTE_TO_MULTI*
>       -f "PostgreSQL" PG:"host=localhost port=5432 user=***
>     password=*** dbname=geodata"
>       FREDSKOV.TAB
>
>     I would expect the table to change the PostGIS type to
>     "MultiPolygon". However it still is registered as "Geometry".
>
>     Checking the table using SQL command:
>
>     SELECT ST_geometrytype(wkb_geometry), count(*) FROM mat.fredskov
>     group by 1
>
>     affirms, that all geometries now is of type "ST_MultiPolygon".
>
>     AFAIK, this is a new behaviour. Or what ?
>
>     Postgres/Postgis version : 13.2,  3.1
>
>     OGR2OGR version:  both 3.4 andf 3.6 dev.
>
>
>
>
>     -- 
>     Med venlig hilsen / Kind regards
>
>     Bo Victor Thomsen
>
>     _______________________________________________
>     gdal-dev mailing list
>     gdal-dev at lists.osgeo.org
>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> -- 
> Richard W. Greenwood
> www.greenwoodmap.com <http://www.greenwoodmap.com>
>
>
> [Fichier texte:ATT00001]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220731/7c14cb8f/attachment.htm>