Skip to main content
Question

POSTGIS Reader different geom column


jorge_vidinha
Contributor
Forum|alt.badge.img+2

Is there any possibility to change the default geometry column 'geom' on postgis readers to some other column with a different geometry like geom2 ?

Thanks

8 replies

Forum|alt.badge.img+2

If you're reading PostGIS then by default FME will pick the first geometry column. If you have multiple geomety columns then FME will only read the first column. FME does not yet support multiple geometry columns on PostGIS. I'm not sure if you could workaround this by formulating a query in SQLExecutor or SQLCreator to select the appropriate geometry


erik_jan
Contributor
Forum|alt.badge.img+17
  • Contributor
  • July 20, 2016

PostGres has the option to create a view (see this link: create view).

FME can select from views

So if you include only the required geometry column in the view and use the view in FME that should work.


jorge_vidinha
Contributor
Forum|alt.badge.img+2
  • Author
  • Contributor
  • July 22, 2016
markatsafe wrote:

If you're reading PostGIS then by default FME will pick the first geometry column. If you have multiple geomety columns then FME will only read the first column. FME does not yet support multiple geometry columns on PostGIS. I'm not sure if you could workaround this by formulating a query in SQLExecutor or SQLCreator to select the appropriate geometry

Thanks Mark . Is readers ready for multi geometry columns support planned for near future releases ?

Regards


jorge_vidinha
Contributor
Forum|alt.badge.img+2
  • Author
  • Contributor
  • July 22, 2016
erik_jan wrote:

PostGres has the option to create a view (see this link: create view).

FME can select from views

So if you include only the required geometry column in the view and use the view in FME that should work.

Thanks erik_jan will look into that workaround - or simple create new table -


rbovard
Contributor
Forum|alt.badge.img
  • Contributor
  • July 16, 2020
markatsafe wrote:

If you're reading PostGIS then by default FME will pick the first geometry column. If you have multiple geomety columns then FME will only read the first column. FME does not yet support multiple geometry columns on PostGIS. I'm not sure if you could workaround this by formulating a query in SQLExecutor or SQLCreator to select the appropriate geometry

markatsafe Do you know if multiple geometry columns on PostGIS will be supported in the future? I'm facing the same issue as jorge_vidinha with 2020.0 and it's annoying (I saw that in Oracle and SQL Server it's supported).

Thanks in advance for the feedback.


virtualcitymatt
Celebrity
Forum|alt.badge.img+35
rbovard wrote:

markatsafe Do you know if multiple geometry columns on PostGIS will be supported in the future? I'm facing the same issue as jorge_vidinha with 2020.0 and it's annoying (I saw that in Oracle and SQL Server it's supported).

Thanks in advance for the feedback.

As as tip for using the SQLCreator or SQLExecutor to see what kind of structure you need for the request you can do the following.

 

 

Set up a FeatureReader (or reader) to the table to you want to read and put in an invalid where clause. In the warning or error that you get FME will return the SQL request it makes to the database including all the column names and how it handles the geometry.

 

 

For PostGIS FME will use something like the below for the geometry column.

 

 

SELECT ST_AsBinary(<geom_column>) (https://postgis.net/docs/ST_AsBinary.html)

 

 

If you use the same call in an SQLCreator or executor you should get the same as from the writer (as in FME should automatically set the geometry)

 

 

If you want to use a different column you can change which column is using the ST_AsBinary.

 

 

If you use both columns with ST_AsBinary (fme will pick one to use as the geometry) and the other will come in as an attribute which you can use the GeometryReplacer set to fme-binary to get the other column as geoemtry as well in a separate path and then aggregate together based on an ID.

 

 

This is the best workaround I have be able to come up with which doesn't require first creating and extra view and reading from two tables. In the end the view approach could be faster but I'm so far unconvinced.

 

 

Good luck

 

 


rbovard
Contributor
Forum|alt.badge.img
  • Contributor
  • July 16, 2020
virtualcitymatt wrote:

As as tip for using the SQLCreator or SQLExecutor to see what kind of structure you need for the request you can do the following.

 

 

Set up a FeatureReader (or reader) to the table to you want to read and put in an invalid where clause. In the warning or error that you get FME will return the SQL request it makes to the database including all the column names and how it handles the geometry.

 

 

For PostGIS FME will use something like the below for the geometry column.

 

 

SELECT ST_AsBinary(<geom_column>) (https://postgis.net/docs/ST_AsBinary.html)

 

 

If you use the same call in an SQLCreator or executor you should get the same as from the writer (as in FME should automatically set the geometry)

 

 

If you want to use a different column you can change which column is using the ST_AsBinary.

 

 

If you use both columns with ST_AsBinary (fme will pick one to use as the geometry) and the other will come in as an attribute which you can use the GeometryReplacer set to fme-binary to get the other column as geoemtry as well in a separate path and then aggregate together based on an ID.

 

 

This is the best workaround I have be able to come up with which doesn't require first creating and extra view and reading from two tables. In the end the view approach could be faster but I'm so far unconvinced.

 

 

Good luck

 

 

Thanks a lot for your workaround!

I like the idea to not create an extra view in the DB and the way you propose to handle these multiple geom fields and keep the link between the features with an ID.

Best regards.


ponceta
Contributor
Forum|alt.badge.img+7
  • Contributor
  • July 22, 2020
rbovard wrote:

Thanks a lot for your workaround!

I like the idea to not create an extra view in the DB and the way you propose to handle these multiple geom fields and keep the link between the features with an ID.

Best regards.

Faced the same issue today, used an sql creator and executor to do the tric. Enhancement idea is here :

https://knowledge.safe.com/idea/117563/native-support-for-postgresql-multiple-geometry-co.html? ;)


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings