Delivered Ideas

Discuss topics with other Hexagon Geospatial Product pioneers and experts to get the most out of our products.
Showing results for 
Search instead for 
Do you mean 

Improve support for "numeric" number format in PostGIS through more precise type mapping

Status: Delivered
by on ‎05-08-2018 12:51 AM - last edited on ‎11-12-2018 01:46 PM by Technical Evangelist

As a GeoMedia user of PostGIS databases, I want GeoMedia to support the "numeric" number format in PostGIS for decimals, so that wrong numbers are not shown in GeoMedia, when I query I do not have to wonder if they are correctly served, and I do not have to manually alter the data type of such fields.


Unfortunately the "numeric" data type is currently not supported by the PostGIS data server and wrong numbers (wrong information) are shown in GeoMedia. The user has to control all of its data to be sure that the right numbers are imported.


It is only possible to work in GeoMedia with this "numeric" number format of PostGIS without issues by transforming the according column into a "double precision" number format.  This workaround is not satisfying because it means to convert every column seperate and manually.

Unnecessary additional effort for the user arises.

Status: Delivered
by Technical Evangelist
on ‎05-08-2018 04:33 AM
Status changed to: Candidate
on ‎07-02-2018 11:30 PM

There is a way to solved or to mitigate your problem without change the table structure. It is to create a view that transform the data type. I have done this to read big integer, that I convert in a text. I haven't try to update information by a view, but probably it was possible,

on ‎07-05-2018 06:46 AM

Thanks for your input! Could be a workaround.

by Technical Evangelist
on ‎07-16-2018 07:47 AM

Nicole, we do have logic for supporting fields of data type numeric, but it is not as sophisticated as that of (for example) our SQL Server data server.  Today it blindly maps such a field to the GDO data type of Double, regardless of its definition.


The work I have captured on our backlog for pursuing this Idea is that we should study the definition of any given numeric field, and intelligently map it to the proper field type such as Integer, Long, Single, or Double as is done for SQL Server.  This will provide more precise and suitable presentation and usage in GeoMedia.


My worry is that this may not be enough for you, because you mention in your Idea a situation we are not seeing - "wrong numbers".  If you think that there is some corruption of data values occurring, then we'll need your help reproducing that, and we would treat it as a Bug rather than an Idea.  In that case, please log a Support Ticket and send some data demonstrating the problem to the support analyst.  Thanks!  - Hal


on ‎07-16-2018 09:41 AM

Why I have used Text and not Double. Currently the user define a Big-Integer (a 64bits number). The first time, the customer export its data with FME to shape and he gave me that files where the Big-Integer is conver in Double.

You can see it pretty with preccsion 2, that is, you see the value 123456789012 but when you do a filter as Field=123456789012 you don't get any registry becuase actually the value saved is 123456789012.00002 (or something like this) and this value is not 123456789012 Smiley Sad

on ‎07-20-2018 04:27 AM

Hi Hal,


There is already a Support Ticket for this case: TN 00028549


Thanks for your support!


Best regards,


by Technical Evangelist
on ‎07-23-2018 09:13 AM

OK, that support ticket includes a couple of snapshots that I guess you provided.  We are not seeing the kind of result you are seeing, based on those snapshots.  While we could announce support for Numeric data type in some future release, I would still be nervous that something is wrong based on what you have seen.  So if you can find the time, please create a backup file of a small PostGIS data case that demonstrates the problem, and send it to me by email so we can make sure we're okay.  Thanks!  - Hal

on ‎09-10-2018 05:55 AM

E-mail with sample data sent to Nicole and Hal.


Thanks for having a look at it!

by Technical Evangelist
on ‎11-12-2018 01:45 PM

We had a look at this data using GeoMedia 2018 Update 2.  We cannot reproduce any problem with presentation of the values from a Numeric column.  We used the data window to visualize the data.


If a problem with Numeric fields still exists for you with Update 2, please file a support ticket outlining the workflow that accompanies the data.  We will treat this particular situation as a Bug if we can reproduce it.


In the meantime we will treat this candidate Idea as a request to further improve the implementation for Numeric fields through more precise field data type mapping.

by Technical Evangelist
on ‎11-08-2019 05:08 AM
Status changed to: Targeted for an upcoming release

This is targeted for GeoMedia 2020 Update 1.  - Hal