Skip to Main Content
IBM Power Ideas Portal
Hide about this portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Improve implementation of Geospatial Data Types

See this idea on ideas.ibm.com

Two parts to this based on observations to date. 

1) 

Currently the supported Geospatial data types, as referenced in QSYS2.SYSTYPES, are based upon BLOB column types. However, you cannot specify the size of the column  like you can with BLOB columns, instead this defaults to 2GB. Seems over the top with respect to ST_POINT and other types where only a small number of values will be specified. Being able to user define the storage size, and possibly the allocated storage, but that doesn't seem so critical, so that it matches the options for BLOB columns would be beneficial. 

2)

I gather that the values are stored in floating point values; which by definition are approximate and differences can be seen between values written via the various QSYS2.ST_???? scalar functions and read via the QSYS2.ST_ASTEXT scalar function. Whilst I am uncertain as to what degree of accuracy values can be stored down to, 8 decimal places is accurate to 1.11mm. Storing the values in a decimal field of DECIMAL(11,8) definition, large enough for the range of values permitted, would only take up 6 bytes per value. Storing the values within the BLOB column in this manner would provide accuracy without the approximation common to floating point values. 

 

Idea priority Medium
  • Guest
    Reply
    |
    Mar 21, 2025
    IBM does not intend to provide a solution to this Idea at this time, so it is being closed.

    The technology behind our Geospatial implementation is supported by the IBM Watson research team. They used floating point for calculations. While we agree that the inexact nature of floating point is hard to explain to others, we cannot modify that part of the solution. Remember, too, that what you perceive as a straight line is not necessarily straight when projected on a spherical earth. Going 100 miles north, 100 miles east, 100 miles south, then 100 miles west does not get you back to your starting point due to the spherical nature of the earth. This is taken into account with our Geospatial support.

    The spatial data types are all BLOB(2G). Each is defined with an ALLOCATE 512 clause to minimize the performance impact for accessing the BLOB storage. Providing built-in data types for Geospatial data to allow the user to provide the length could be done, but it has a very high cost and will not be implemented.

    Db2 for i development team
    IBM Power Systems Development