PostGIS

​https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines 1) As strk mentioned in #3334 there is a new feature that will automatically close a ticket if we put it as part of the commit log entry. That should be added. 2) There is no mention ... [More] of SFCGAL in the relationships section or json-c or libxml. (json-c, libxml probably doesn't need mentioning since they are core parts of a lot of projects). 3) Our guidelines don't detail our protocol for pull requests and stuff from currently github, and potentionally gitlab. [Less]

==2979==ERROR: LeakSanitizer: detected memory leaks Direct leak of 128 byte(s) in 1 object(s) allocated from: #0 0x55ff8a5fd3c1 in __interceptor_malloc (/home/raul/dev/public/postgis/liblwgeom/cunit/.libs/lt-cu_tester+0x13b3c1) #1 ... [More] 0x7faf98a0394b in rect_node_internal_new /home/raul/dev/public/postgis/liblwgeom/lwtree.c:566:20 #2 0x7faf98a0394b in rect_nodes_merge /home/raul/dev/public/postgis/liblwgeom/lwtree.c:604 #3 0x7faf98a0394b in rect_tree_from_lwcurvepoly /home/raul/dev/public/postgis/liblwgeom/lwtree.c:803 #4 0x7faf98a0394b in rect_tree_from_lwgeom /home/raul/dev/public/postgis/liblwgeom/lwtree.c:868 #5 0x55ff8a653495 in test_rect_tree_contains_point /home/raul/dev/public/postgis/liblwgeom/cunit/cu_measures.c:212:9 SUMMARY: AddressSanitizer: 4856 byte(s) leaked in 40 allocation(s). GH PR: ​https://github.com/postgis/postgis/pull/216 I'll see if I can push this myself. [Less]

I have found bugs in the three PostGIS functions providing temporal support, that is ST_ClosestPointOfApproach, ST_DistanceCPA, ST_CPAWithin. In the examples below, the M values of the geometries keep the timestamps encoded in epoch, that is, in ... [More] seconds since 1970-01-01. select to_timestamp(ST_ClosestPointOfApproach( geometry 'LINESTRING M ( 3002640.82925984 5833770.09678249 1180471354.482, 3003084.56741608 5833866.22147656 1180471411.791, 3003325.8165722 5833942.66399188 1180471442.914, 3003634.9521919 5834039.57644606 1180471482.436, 3003701.57229565 5833872.50949516 1180471494.55)', geometry 'LINESTRING M ( 2996311.19255982 5844593.73486637 1180471513.163, 2996310.72190852 5844712.60937002 1180471523.37, 2996311.81673704 5844916.90864168 1180471541.171)' )); -- "2007-05-29 20:43:44+00" The two geometries do not intersect in the time dimension as can be seen next. select tstzrange(to_timestamp(1180471354.482), to_timestamp(1180471494.55)) as r1, tstzrange(to_timestamp(1180471513.163), to_timestamp(1180471541.171)) as r2, tstzrange(to_timestamp(1180471354.482), to_timestamp(1180471494.55)) * tstzrange(to_timestamp(1180471513.163), to_timestamp(1180471541.171)) as intersection -- "["2007-05-29 20:42:34.482+00","2007-05-29 20:44:54.55+00")"; -- "["2007-05-29 20:45:13.163+00","2007-05-29 20:45:41.171+00")"; -- "empty" select ST_DistanceCPA ( geometry 'LINESTRING M ( 3002640.82925984 5833770.09678249 1180471354.482, 3003084.56741608 5833866.22147656 1180471411.791, 3003325.8165722 5833942.66399188 1180471442.914, 3003634.9521919 5834039.57644606 1180471482.436, 3003701.57229565 5833872.50949516 1180471494.55)', geometry 'LINESTRING M ( 2996311.19255982 5844593.73486637 1180471513.163, 2996310.72190852 5844712.60937002 1180471523.37, 2996311.81673704 5844916.90864168 1180471541.171)' ); -- 1.84467435239537e+19 Again, the two geometries do not intersect in the time dimension as can be seen next. select tstzrange(to_timestamp(1180471354.482), to_timestamp(1180471494.55)) as r1, tstzrange(to_timestamp(1180471513.163), to_timestamp(1180471541.171)) as r2, tstzrange(to_timestamp(1180471354.482), to_timestamp(1180471494.55)) * tstzrange(to_timestamp(1180471513.163), to_timestamp(1180471541.171)) as intersection -- "["2007-05-29 20:42:34.482+00","2007-05-29 20:44:54.55+00")"; -- "["2007-05-29 20:45:13.163+00","2007-05-29 20:45:41.171+00")"; -- "empty" Another example that raises an error select st_distanceCPA( geometry 'LINESTRING M ( 2997192.88890412 5839689.91506735 1180427687.535, 2985681.00213108 5848959.94022801 1180428894.461, 2985654.50641456 5848965.14626724 1180428897.729)', geometry 'LINESTRING M ( 3010311.09650771 5836055.09743228 1180426478.189, 2997990.4548773 5837170.57877078 1180427568.652, 2997958.79103681 5837131.44898043 1180427572.06)' ) ERROR: Could not find point with M=4.85636e-33 on first geom select tstzrange(to_timestamp(1180427687.535), to_timestamp(1180428897.729)) as r1, tstzrange(to_timestamp(1180426478.189), to_timestamp(1180427572.06)) as r2, tstzrange(to_timestamp(1180427687.535), to_timestamp(1180428897.729)) * tstzrange(to_timestamp(1180426478.189), to_timestamp(1180427572.06)) as intersection -- "["2007-05-29 08:34:47.535+00","2007-05-29 08:54:57.729+00")"; -- "["2007-05-29 08:14:38.189+00","2007-05-29 08:32:52.06+00")"; -- "empty" Finally, an example where the function raises a warning. select st_cpawithin( geometry 'LINESTRING M ( 3019128.43134286 5840247.67862383 1180456071.042, 3019119.61305787 5840246.74066617 1180456073.042, 2996737.82023413 5844599.06195388 1180457771.512, 2996737.59384604 5844601.28272594 1180457771.789)', geometry 'LINESTRING M ( 3009712.72081161 5845603.63178027 1180455259.727, 3005699.98574744 5843414.54803783 1180455707.126, 3005620.80433525 5839623.27707574 1180456050.83, 3005625.01275697 5839609.12408978 1180456052.609)', 10); NOTICE: Could not find point with M=4.68292e-310 on first geom [Less]

Finally got winnie back to working again and ogsh darnit a real failure. ============== running regression test queries ============== test test-init-extensions ... ok test test-parseaddress ... FAILED test ... [More] test-standardize_address_1 ... ok test test-standardize_address_2 ... ok Hard to say when this started since my SFCGAL misconfig has had her out of commission for almost a month [Less]

I was looking at why gitlab is failing on recent tests. It's showing this. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'postgresql-9.4' has no installation candidate E: Unable ... [More] to locate package postgresql-server-dev-9.4 E: Couldn't find any package by glob 'postgresql-server-dev-9.4' E: Couldn't find any package by regex 'postgresql-server-dev-9.4' E: Unable to locate package libjson0-dev ERROR: Job failed: exit code 1 [Less]

When casting an actual BOX3D to geometry, the result is invalid. If it has a width of 0 in one ore more dimensions, it is fine. The problem is that the orientations of the top, front and left side of the polyhedral surface are wrong. Example: ... [More] > SELECT ST_AsText('BOX3D(1 2 3,4 5 6)'::BOX3D); POLYHEDRALSURFACE Z (((1 2 3,1 5 3,4 5 3,4 2 3,1 2 3)),((1 2 6,1 5 6,4 5 6,4 2 6,1 2 6)),((1 2 3,1 5 3,1 5 6,1 2 6,1 2 3)),((4 2 3,4 5 3,4 5 6,4 2 6,4 2 3)),((1 2 3,4 2 3,4 2 6,1 2 6,1 2 3)),((1 5 3,4 5 3,4 5 6,1 5 6,1 5 3))) -- expected correct result: POLYHEDRALSURFACE Z (((1 2 3,1 5 3,4 5 3,4 2 3,1 2 3)),((1 2 6,4 2 6,4 5 6,1 5 6,1 2 6)),((1 2 3,1 2 6,1 5 6,1 5 3,1 2 3)),((4 2 3,4 5 3,4 5 6,4 2 6,4 2 3)),((1 2 3,4 2 3,4 2 6,1 2 6,1 2 3)),((1 5 3,1 5 6,4 5 6,4 5 3,1 5 3))) Notice the switched coordinates for the second (top), third (left) and sixth (front) polygon. This results e.g. in ST_Volume and ST_3DArea not accepting "true" BOX3Ds: > SELECT ST_3DArea('BOX3D(1 2 3,1 5 6)'::BOX3D); -- works 9 > SELECT ST_3DArea('BOX3D(1 2 3,4 5 6)'::BOX3D); -- doesn't work SQL Error [XX000]: ERROR: Solid is invalid : PolyhedralSurface (shell) 0 is invalid: not connected : SOLID((((1/1 2/1 3/1,1/1 5/1 3/1,4/1 5/1 3/1,4/1 2/1 3/1,1/1 2/1 3/1)),((1/1 2/1 6/1,1/1 5/1 6/1,4/1 5/1 6/1,4/1 2/1 6/1,1/1 2/1 6/1)),((1/1 2/1 3/1,1/1 5/1 3/1,1/1 5/1 6/1,1/1 2/1 I think the error is at postgis/lwgeom_box3d.c, lines 325-342. I'm using: PostgreSQL 10.1, compiled by Visual C++ build 1800, 64-bit POSTGIS="2.4.3 r16312" PGSQL="100" GEOS="3.6.2-CAPI-1.10.2 4d2925d" SFCGAL="1.3.2" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.3, released 2017/11/20" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" RASTER [Less]

I just noticed today that many of the trac bot badges are not showing. ​https://trac.osgeo.org/postgis What is weird is when I looked earlier today I only saw winnie's badges. Now I'm only seeing dronie badges. I suspect it has something to ... [More] do with the tracvm upgrade Martin Spott did last night. But before I report to OSGeo trac want to confirm that. pramsey mentioned in IRC he's seeing the same behavior. So must be some weird caching in trac. IRC log notes 21:33:08 robe2: pramsey, bj0rn[m], dbaston -- check out trac and see if you run into any issues -- trac is now running on PostgreSQL 10.2 21:33:40 robe2: https://trac.osgeo.org/osgeo/ticket/2109 21:33:41 sigq: Title: #2109 (trac postgresql needs to be upgraded) – OSGeo (at trac.osgeo.org) 21:35:25 robe2: is it just me or all our badges missing - https://trac.osgeo.org/postgis/ I never know cause I'm always vpned into so many networks 21:35:27 sigq: Title: PostGIS (at trac.osgeo.org) 22:37:19 pramsey: It’s not you, all the badges are missing. 22:38:15 pramsey: although, following the image urls, returns a valid image https://debbie.postgis.net/buildStatus/icon?job=PostGIS_trunk 22:38:30 pramsey: so… I wonder why they aren’t rendering in the wiki page I cleared by cache and same issue on both on chrome and firefox. When I look at the net calls I see that the image calls were canceled and this shows: Request URL:https://debbie.postgis.net/buildStatus/icon?job=PostGIS_trunk Referrer Policy:no-referrer-when-downgrade Provisional headers are shown Origin:https://trac.osgeo.org Referer:https://trac.osgeo.org/postgis User-Agent:Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Mobile Safari/537.36 job:PostGIS_trunk badge Images show fine on gitea and github. [Less]

Linearizing a GEOMETRYCOLLECTION is supported but now the other way around. Here is the PR that adds it: ​https://github.com/postgis/postgis/pull/209 It also forces all clone calls to be _clone_deep to memory corruption in the tests when some ... [More] parts of the input and output geometries where shared; for example when passed GEOMETRYCOLLECTION(LINESTRING(10 10,10 11),LINESTRING(10 11,11 11),LINESTRING(11 11,10 10)). [Less]

We have experienced frequent crashes in PostGIS, with backtraces pointing to memory corruption in the lwgeom lexer. I believe the attached patch fixes the problem. We have had it running for about a week without crashes, where before, they were ... [More] quite frequent. The problem is that if a query is aborted while the lexer is running (e.g., statement timeout), the memory belonging to the internal lexer state is cleaned up by PostgreSQL, but the flex code thinks it's still there, so it will crash the next time the lexer runs. The fix is to reinitialize the flex globals before each run. (The same problem once existed in the core PostgreSQL code.) The problem was observed in version 2.2, but the same code exists in trunk as well. I suggest the fix could be backpatched. (You should regenerated the .c files using your preferred flex version.) [Less]

postgis 2.4.3 failed to build with proj 5.0.0-rc2 due to the tickets test failing: *** /tmp/pg_virtualenv.38D232/log/postgresql-10-regress.log (last 100 lines) *** ST_AsText(g::geometry), ST_OrderingEquals(g::geometry ... [More] , St_GeomFromText(ST_AsText(g::geometry))) FROM ( SELECT 'CURVEPOLYGON (COMPOUNDCURVE(CIRCULARSTRING(0 0,1 1,1 0),(1 2,0 1)))' ::text as g ) as foo; 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg ERROR: geometry requires more points 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg HINT: "CURVEPOLYGON (COMPOUNDCURVE EMPTY)" <-- parse error at position 34 within geometry 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg STATEMENT: SELECT g, ST_AsText(g::geometry), ST_OrderingEquals(g::geometry, St_GeomFromText(ST_AsText(g::geometry))) FROM ( SELECT 'CURVEPOLYGON (COMPOUNDCURVE EMPTY)' ::text as g ) as foo; 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg ERROR: geometry contains non-closed rings 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg HINT: "...RCULARSTRING(0 0,1 1,1 0),(1 0,0 1)))" <-- parse error at position 67 within geometry 2018-02-09 16:38:58.449 UTC [16809] pbuilder@postgis_reg STATEMENT: SELECT g, ST_AsText(g::geometry), ST_OrderingEquals(g::geometry, St_GeomFromText(ST_AsText(g::geometry))) FROM ( SELECT 'CURVEPOLYGON (COMPOUNDCURVE(CIRCULARSTRING(0 0,1 1,1 0),(1 0,0 1)))' ::text as g ) as foo; 2018-02-09 16:38:58.454 UTC [16809] pbuilder@postgis_reg ERROR: geometry contains non-closed rings 2018-02-09 16:38:58.454 UTC [16809] pbuilder@postgis_reg HINT: "TRIANGLE ((1 2 3,4 5 6,7 8 9,1 2 0))" <-- parse error at position 37 within geometry 2018-02-09 16:38:58.454 UTC [16809] pbuilder@postgis_reg STATEMENT: SELECT g, ST_AsText(g::geometry), ST_OrderingEquals(g::geometry, St_GeomFromText(ST_AsText(g::geometry))) FROM ( SELECT 'TRIANGLE ((1 2 3,4 5 6,7 8 9,1 2 0))' ::text as g ) as foo; 2018-02-09 16:38:58.455 UTC [16809] pbuilder@postgis_reg ERROR: geometry contains non-closed rings 2018-02-09 16:38:58.455 UTC [16809] pbuilder@postgis_reg HINT: "...0 0 0 1, 0 1 0 2, 1 1 0 3, 0 1 0 1)) " <-- parse error at position 88 within geometry 2018-02-09 16:38:58.455 UTC [16809] pbuilder@postgis_reg STATEMENT: SELECT g, ST_AsText(g::geometry), ST_OrderingEquals(g::geometry, St_GeomFromText(ST_AsText(g::geometry))) FROM ( SELECT 'TIN ZM ( ((0 0 0 0, 0 0 1 0, 0 1 0 4, 0 0 0 0)), ((0 0 0 1, 0 1 0 2, 1 1 0 3, 0 1 0 1)) )' ::text as g ) as foo; 2018-02-09 16:38:58.644 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_2d signature was deprecated in 2.1.0. Please use ST_Force2D 2018-02-09 16:38:58.644 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_2d" during startup 2018-02-09 16:38:58.645 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_2d signature was deprecated in 2.1.0. Please use ST_Force2D 2018-02-09 16:38:58.645 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_2d" during startup 2018-02-09 16:38:58.645 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_2d signature was deprecated in 2.1.0. Please use ST_Force2D 2018-02-09 16:38:58.645 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_2d" during startup 2018-02-09 16:38:58.650 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_2d signature was deprecated in 2.1.0. Please use ST_Force2D 2018-02-09 16:38:58.650 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_2d" during startup 2018-02-09 16:38:58.650 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_Collection signature was deprecated in 2.1.0. Please use ST_ForceCollection 2018-02-09 16:38:58.650 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_collection" during startup 2018-02-09 16:38:58.654 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_2d signature was deprecated in 2.1.0. Please use ST_Force2D 2018-02-09 16:38:58.654 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_2d" during startup 2018-02-09 16:38:58.654 UTC [16813] pbuilder@postgis_reg WARNING: ST_Force_Collection signature was deprecated in 2.1.0. Please use ST_ForceCollection 2018-02-09 16:38:58.654 UTC [16813] pbuilder@postgis_reg CONTEXT: PL/pgSQL function _postgis_deprecate(text,text,text) line 14 at RAISE SQL function "st_force_collection" during startup 2018-02-09 16:39:18.262 UTC [16933] pbuilder@postgis_reg ERROR: ST_OffsetCurve only works with LineStrings 2018-02-09 16:39:18.262 UTC [16933] pbuilder@postgis_reg STATEMENT: SELECT 't0', ST_OffsetCurve('POINT(0 0)', 10); 2018-02-09 16:39:18.346 UTC [16945] pbuilder@postgis_reg ERROR: Operation on mixed SRID geometries 2018-02-09 16:39:18.346 UTC [16945] pbuilder@postgis_reg STATEMENT: select 't1', st_asewkt(st_sharedpaths( 'SRID=10;LINESTRING(0 0, 10 0)', 'SRID=5;LINESTRING(0 0, 100 0)' )); 2018-02-09 16:39:18.348 UTC [16945] pbuilder@postgis_reg ERROR: GEOSSharedPaths: IllegalArgumentException: Geometry is not lineal 2018-02-09 16:39:18.348 UTC [16945] pbuilder@postgis_reg STATEMENT: select 't6', st_sharedpaths( '0101000020E6100000F771D98DE33826C00000000000004440'::geometry, '0103000020E61000000100000021000000F771D98DE33820C00000000000004E409610DB16675620C00EC34AD715B54D407AF7FF56CFAD20C008E817B00C6D4D40A8B32666C03B21C017D34B39A92A4D40C096A1DAC5FA21C03309329378F04C4050BE087388E322C06D501336B7C04C401412394E16ED23C061A149F23A9D4C402C7E04EB3A0D25C0A86740E260874C40F471D98DE33826C00000000000804C40BC65AE308C6427C0A86740E260874C40D5D179CDB08428C060A149F23A9D4C409A25AAA83E8E29C06C501336B7C04C402A4D114101772AC03209329378F04C4043308CB506362BC016D34B39A92A4D4072ECB2C4F7C32BC007E817B00C6D4D4057D3D704601B2CC00DC34AD715B54D40F771D98DE3382CC0FFFFFFFFFFFF4D4059D3D704601B2CC0F13CB528EA4A4E4076ECB2C4F7C32BC0F717E84FF3924E4049308CB506362BC0E82CB4C656D54E40324D114101772AC0CCF6CD6C870F4F40A325AAA83E8E29C093AFECC9483F4F40DFD179CDB08428C09F5EB60DC5624F40C665AE308C6427C05898BF1D9F784F40FD71D98DE33826C00000000000804F40347E04EB3A0D25C05898BF1D9F784F401B12394E16ED23C0A05EB60DC5624F4056BE087388E322C094AFECC9483F4F40C496A1DAC5FA21C0CEF6CD6C870F4F40ABB32666C03B21C0EA2CB4C656D54E407CF7FF56CFAD20C0F917E84FF3924E409710DB16675620C0F33CB528EA4A4E40F771D98DE33820C00000000000004E40'::geometry ); 2018-02-09 16:39:18.367 UTC [16949] pbuilder@postgis_reg ERROR: Operation on mixed SRID geometries 2018-02-09 16:39:18.367 UTC [16949] pbuilder@postgis_reg STATEMENT: select 't1', st_asewkt(st_snap( 'SRID=10;LINESTRING(0 0, 10 0)', 'SRID=5;LINESTRING(0 0, 100 0)', 0 )); 2018-02-09 16:39:18.802 UTC [16965] pbuilder@postgis_reg ERROR: GEOSRelate: Invalid boundary node rule 5 2018-02-09 16:39:18.802 UTC [16965] pbuilder@postgis_reg STATEMENT: SELECT st_relate('POINT(0 0)', 'POINT(1 0)', 5); 2018-02-09 16:39:18.856 UTC [16973] pbuilder@postgis_reg ERROR: lwgeom_subdivide: cannot subdivide to fewer than 8 vertices per output 2018-02-09 16:39:18.856 UTC [16973] pbuilder@postgis_reg STATEMENT: SELECT '#3135', st_astext(ST_SubDivide(ST_GeomFromText('POLYGON((1 2,1 2,1 2,1 2))'), 2)); 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg ERROR: Tolerance must be a positive number. 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg CONTEXT: SQL function "st_voronoipolygons" statement 1 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg STATEMENT: SELECT 3, ST_VoronoiPolygons('MULTIPOINT (0 0, 1 1, 2 2)', NULL); 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg ERROR: Tolerance must be a positive number. 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg CONTEXT: SQL function "st_voronoipolygons" statement 1 2018-02-09 16:39:18.993 UTC [16981] pbuilder@postgis_reg STATEMENT: SELECT 5, ST_VoronoiPolygons('MULTIPOINT (0 0, 1 1, 2 2)', -2); 2018-02-09 16:39:19.036 UTC [16989] pbuilder@postgis_reg ERROR: Unable to find 'coordinates' in GeoJSON string 2018-02-09 16:39:19.036 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.1',ST_GeomFromGeoJSON('{ "type": "Point", "crashme": [100.0, 0.0] }'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: unexpected character (at offset 0) 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.2',ST_GeomFromGeoJSON('crashme'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: unexpected end of data (at offset 0) 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.3',ST_GeomFromGeoJSON(''); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: invalid GeoJSON representation 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.4',ST_GeomFromGeoJSON('{}'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: Too few ordinates in GeoJSON 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.5',ST_GeomFromGeoJSON('{"type":"Point","coordinates":[]}'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: Too few ordinates in GeoJSON 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.6',ST_GeomFromGeoJSON('{"type":"MultiPoint","coordinates":[[]]}'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: Unable to find 'coordinates' in GeoJSON string 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.7',ST_GeomFromGeoJSON('{"type":"MultiPoint"}'); 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg ERROR: Unable to find 'coordinates' in GeoJSON string 2018-02-09 16:39:19.037 UTC [16989] pbuilder@postgis_reg STATEMENT: select '#1434.8',ST_GeomFromGeoJSON('{"type":"Point"}'); 2018-02-09 16:39:19.038 UTC [16989] pbuilder@postgis_reg ERROR: The 'coordinates' in GeoJSON ring are not an array 2018-02-09 16:39:19.038 UTC [16989] pbuilder@postgis_reg STATEMENT: SELECT '#2697', ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[1]}'); 2018-02-09 16:39:19.038 UTC [16989] pbuilder@postgis_reg ERROR: The 'coordinates' in GeoJSON ring are not an array 2018-02-09 16:39:19.038 UTC [16989] pbuilder@postgis_reg STATEMENT: SELECT '#2697', ST_GeomFromGeoJSON('{"type":"Polygon","coordinates":[1,1]}'); 2018-02-09 16:39:20.076 UTC [17005] pbuilder@postgis_reg ERROR: pgis_asmvt_transfn: parameter row cannot be other than a rowtype 2018-02-09 16:39:20.076 UTC [17005] pbuilder@postgis_reg STATEMENT: SELECT encode(ST_AsMVT(1, 'test', 4096, 'geom'), 'base64'); Dropping cluster 10/regress ... ### /tmp/pgis_reg/test_91_diff ### --- tickets_expected 2018-01-16 05:31:17.000000000 +0000 +++ /tmp/pgis_reg/test_91_out 2018-02-09 16:38:53.269350614 +0000 @@ -198,7 +198,7 @@ #1578|f|f #1580.1|Point[S] ERROR: transform: couldn't project point (180 90 0): tolerance condition error (-20) -#1580.3|Point[S] +ERROR: transform: couldn't project point (0 0 0): tolerance condition error (-20) #1596.1|public.road_pg.roads_geom SRID:3395 TYPE:POINT DIMS:2 ERROR: invalid SRID: 330000 not found in spatial_ref_sys #1596.3|3395 @@ -207,7 +207,7 @@ NOTICE: SRID value -1 converted to the officially unknown SRID value 0 #1596.6|public.road_pg.roads_geom SRID changed to 0 #1596.7|0 -#1596|Point[GS] +ERROR: transform: couldn't project point (-176 -22 0): tolerance condition error (-20) #1695|MULTIPOLYGON EMPTY #1697.1|0 #1697.2|0 ### end of log dumps ### [Less]