Opened 6 years ago

Closed 6 years ago

#3957 closed defect (invalid)

ST_StartPoint - not works correctly

Reported by: sanyasi Owned by: pramsey
Priority: medium Milestone: PostGIS 2.4.4
Component: postgis Version: 2.4.x
Keywords: Cc:

Description (last modified by robe)

In the Quantum, I draw a point, and the line emerging from it.

1)

select ST_x(ST_StartPoint(geo)),ST_y(ST_StartPoint(geo)),ST_StartPoint(geo),geo from devicelink WHERE "gid"=17178;

2)

SELECT ST_x(geo),ST_y(geo),geo FROM map.devices WHERE ip='192.168.1.1';

1)

36.1191425241613;56.7842403055775;"0101000020E6100000F46AEE0F400F4240825480FC61644C40";"0102000020E610000002000000F46AEE0F400F4240825480FC61644C401998EA8F410F4240DCEC82F163644C40"

2)

36.1191425241613;56.7842403055775;"0101000020E6100000F76AEE0F400F4240835480FC61644C40"

"PostgreSQL 9.5.10 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4, 64-bit POSTGIS="2.4.2 r16113" PGSQL="95" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.1, released 2013/08/26" LIBXML="2.9.1" L (…)"

POSTGIS="2.3.2" works correctly

Change History (11)

comment:1 by robe, 6 years ago

Description: modified (diff)

comment:2 by robe, 6 years ago

I'm not seeing a difference in the answers you posted. Can you elaborate.

In both return the X and Y is the same. In the first you have an additional output for your additional select column

ST_StartPoint(geo)

in your sql so that doesn't expose any difference (the results are different as expected) since have one less column selected in your second query.

comment:3 by sanyasi, 6 years ago

1- 0101000020E6100000F46AEE0F400F4240825480FC61644C40

2- 0101000020E6100000F76AEE0F400F4240835480FC61644C40

but should be the same

comment:4 by pramsey, 6 years ago

Resolution: invalid
Status: newclosed

Without some attached data that shows the problem, this won't get touched. The two queries run on different tables with different data, and the results are… different. The fact that the human-readable versions appear the same wouldn't surprise you if they were rounded to the nearest 0.1. Would it surprise you to know that the binary representations differ only in the two least-significant bits? The human readable forms just happen to be rounded off before you can see those differences.

comment:5 by sanyasi, 6 years ago

If I manually change the binaries to the old version, then the function returns the same results. The problem is not in the database data.

comment:6 by sanyasi, 6 years ago

Resolution: invalid
Status: closedreopened

comment:7 by sanyasi, 6 years ago

In my information system, which checks the contact points and lines, there are errors in the transition to the new version.

comment:8 by robe, 6 years ago

Milestone: PostGIS 2.4.3PostGIS 2.4.4

sanyasi,

Can you provide some data that we can clearly check and output from 2.3.2 and your new.

I'll keep this open for now, but it's really hard to troubleshoot something we don't see.

comment:9 by sanyasi, 6 years ago

Of course, you can insert in two tables the data that I have given and make queries with different versions

INSERT 0102000020E610000002000000F46AEE0F400F4240825480FC61644C401998EA8F410F4240DCEC82F163644C40 to devicelink (geo) LINESTRING WGS 84 (4326)

INSERT 0101000020E6100000F76AEE0F400F4240835480FC61644C40 to devices (geo) POINT WGS 84 (4326)

and execute on them the requests that I indicated with different versions of binaries

Last edited 6 years ago by sanyasi (previous) (diff)

comment:10 by pramsey, 6 years ago

Can you write out, in SQL, a set of steps I can copy and paste into my terminal that will, when run on the different versions you indicate, output different results?

comment:11 by pramsey, 6 years ago

Resolution: invalid
Status: reopenedclosed

Without a replicable test case and explanation I have to close this.

Note: See TracTickets for help on using tickets.