11-25-2016 03:46 PM
Can someone confirm if the PostGIS data server for GeoMedia supports MultiPolygons? Based on reading the documentation and my own testing, I am coming up with an answer of no. However, I have a hard time beleiving it is not supported as it is a widely used geometry type. My specific use case is a county parcel layer. I am able to view the feature, but cannot edit it.
11-25-2016 03:54 PM
If you mean the new GM 2016 PostGIS data server, it does not distinguish between geometry types and stores all as one generic type "GEOMETRY". So if your geometry type is restricted to MULTIPOLYGON, it is possibly the reason why the table is read only. Another reason might be missing the ctid column (table with oids = false). As a workaround I suggest you to create a new table using GeoMedia and then use the "Output to Feature Classes" command to copy the data into a new table. Then it should start to be read/write.
11-29-2016 10:38 AM
Thanks Pavel, using the generic GEOMETRY type does solve the issue within GeoMedia as it does accept the multipart features. However, this does bring up a new issue that I see other users are having as well (http://community.hexagongeospatial.com/t5/Support-GeoMedia/PostGIS-tables-created-by-GeoMedia-can-t-...) and that is support for other applications accessing the database. In the above post there is mention of a development evaluation being requested, is that something that could be shared?
The "add-on" data adapter that was available for use in GM 2015 supported explicitly defined data types which worked very nicely with other applications. I can see from this post (http://community.hexagongeospatial.com/t5/Support-GeoMedia/Post-Gis-new-Connection/m-p/8074/highligh...) that this adapter should work with GM 2016, but will that continue to be true in future GeoMedia releases? If so, then we could leave our data as explicitly defined and use the add-on adapter to facilitate interoperability.
11-29-2016 12:08 PM
For GeoMedia there are 2 methods (data servers) that can be used to connect to a Postgres/PostGIS database:
Of these two methods, only newer "PostGIS Read-Write" data server is fully supported.
CR defect 1-M0LGMF reported an issue where certain PostGIS geometry generated by GeoMedia 2016 could not be displayed in QGIS. It was found that the problem occurred for geometry containing arcs and/or geometry collections. In the case of arc geometry, it was found that the version of QGIS needed to be upgraded to a higher version that supported display of arcs.
The GeoMedia 2016 PostGIS Read-Write data server writes geometry collections as GEOMETRYCOLLECTION. The collection geometry produced by GeoMedia passes OGC validation checks using tools/functions such as ST_IsValid and ST_IsValidReason.
Select id1, ST_IsValidReason (geometry_spa) from polygons;
Unfortunately, QGIS does not currently support the GEOMETRYCOLLECTION type. This means that geometry collections will not display in the QGIS application. This is an issue that should be reviewed and possibly addressed by QGIS.
It may be possible however to convert in a SQL window the geometry to a MULTI format as a post process step or a possibly even a trigger using the ST_CollectionExtract function.
-- Constants: 1 == POINT, 2 == LINESTRING, 3 == POLYGON
ALTER TABLE parcels
ALTER COLUMN geometry_spa TYPE geometry(MultiPolygonZ,32054) USING ST_CollectionExtract(geometry_spa,3);
The older PostGIS data server is not delivered with 2016 but can be installed on a 2016 system so it is possible for you to connect to your data in its current form. We suggest however that you consider migrating from the older PostGIS data sever to the newer supported Post GIS Read-Write data sever.
If you want to conform to the newer PostGIS Read-Write format then the easiest method is to:
Output to Feature Classes will write the data and the metadata in the conventions required by the newer PostGIS Read Write data server delivered in GeoMedia 2016. There are no in-place conversion tools or utility. You could keep the older database in place for the older clients and older GeoWorkSpaces references that may be using the unsupported CodePlex version.
11-30-2016 05:30 AM
And regarding the lack of QGIS support for GeometryCollection, we are considering an enhancement to the data server to accommodate this by creating more finely-typed collections when possible. E.g. if an area collection happens to be composed solely of areas that can be modeled as WKB polygons, then write a MultiPolygon, reverting to write of a GeometryCollection only when there are one or more items in the collection containing arcs. This enhancement will not be in 16.1, but will be a candidate for 17.0. - Hal
11-30-2016 06:26 AM
Regarding the old version, see the Native geometry format section. To be more compatible with other OSS, the old version always create tables with geometry types, which don't support arcs. If you want to store arcs, you can create the table manually and create metadata for this table.
Regarding the support of old version, the advantage is that this is open source version. So it will always be "supported" in terms, that anybody can take over it and fix possible issues. The disadvantage is that there will always be issues, which must be "fixed" on the other side.