PostGIS ST_GeomFromGML giving strange result
I'm currently running Postgres 9.1 with PostGIS 2.0.
I am trying to create a polygon geometry from the following GML:
51.018333435058594 14.270000457763672 51.016666412353516 14.399999618530273 51.003334045410156 14.566666603088379 50.95805740356445 14.574999809265137 50.90277862548828 14.38611125946045 50.9183349609375 14.398333549499512 50.94166564941406 14.396666526794434 50.95000076293945 14.300000190734863 51.018333435058594 14.270000457763672
So I run the following command:
INSERT INTO test (polygon) VALUES ( (SELECT ST_GeomFromGML( 'gml') ) )
This executes correctly and produces a geometry in the table. However when I come to view the geometry in Quantum GIS there is clearly a problem and when I retrieve the GML through PostGIS I get the following:
SELECT ST_AsGML( polygon ) from test where id=1;
14.270000457763672,51.018333435058594 14.399999618530273,51.016666412353516 14.566666603088379,51.003334045410156 14.574999809265137,50.958057403564453 14.386111259460449,50.902778625488281 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.399999618530273,51.016666412353516 14.566666603088379,51.003334045410156 14.574999809265137,50.958057403564453 14.386111259460449,50.902778625488281 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.566666603088379,51.003334045410156 14.574999809265137,50.958057403564453 14.386111259460449,50.902778625488281 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.574999809265137,50.958057403564453 14.386111259460449,50.902778625488281 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.386111259460449,50.902778625488281 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.398333549499512,50.9183349609375 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.396666526794434,50.941665649414062 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.300000190734863,50.950000762939453 14.270000457763672,51.018333435058594 14.270000457763672,51.018333435058594
I am slightly concerned that the Lat/long points have been reversed in the output but at the moment my main problem is that the nine original points are repeated and with each repeat one point is removed causing the rendering of the geometry to be useless and causing it to be useless for any further calculations.
Can someone please give me an idea of what I'm doing wrong.
I can repeat your issue with your GML. It seems that PostGIS does not like it. I can't say if there is something wrong in the GML or bug in PostGIS or just missing support for that GML version but I could insert a similar geometry as follows:
CREATE TABLE gml_test (id integer, geometry geometry);
Insert geometry as GML3:
insert into gml_test values(4, st_geomfromgml('
')); 51.018333435058594 14.270000457763672 51.016666412353516 14.399999618530273 51.003334045410156 14.566666603088379 50.958057403564453 14.574999809265137 50.902778625488281 14.386111259460449 50.9183349609375 14.398333549499512 50.941665649414062 14.396666526794434 50.950000762939453 14.300000190734863 51.018333435058594 14.270000457763672
The coordinate order is OK. PostGIS is using internally longitude-latitude order but it knows that "urn:ogc:def:crs:EPSG::4326" that was used in input means that coordinates are presented in latitude-longitude.
Where did you get your GML? If it is valid I would suggest to ask why it does not behave well from postgis-users mailing list.
After upgrading to postgres 9.4 and PostGIS 2.1 the problem is resolved. Having searched around the PostGIS tickets it looks as if this was the original problem and was fixed in 2.1.4.
Merge two lists of different objects
i'm using api requests that returns a list. -the first api request returns a list of object that contains (user_id,content,date,title) -the second response returns list of object too that contains (user_id,user_name).
i want to merge the two list the display them into one recycler view but keep user name instead of user_id.this image breaks down what i want clearly.
apprecuiate any help i'm really stuck in this and i need it ty .
Weird resolution on Ubuntu 21.04
I just installed Ubuntu 21.04 on my Asus UX370UAF (dual boot with Windows 10) and its native resolution was automatically set to 1920x1080 (16:9). Since the screen size is 13.3'' everything is a bit "small", especially fonts, texts, labels and so on. I tried changing the scale setting it to 125% and 150%, but the result is a bit blurred and kinda "out of focus". I also tried using the "Big characters" option in the Universal Access Settings tab, but then again it looks a bit small anyway.
I think the best option is to leave it with its native resolution but it's like Ubuntu thinks my screen is way bigger than it actually is. Does anyone know how to fix this?
A.4. Release 2.4.3
This is a bug fix and performance improvement release.
Bug Fixes and Enhancements
#3713, Support encodings that happen to output a '' character
#3827, Set configure default to not do interrupt testing, was causing false negatives for many people. (Regina Obe) revised to be standards compliant in #3988 (Greg Troxel)
#3930, Minimum bounding circle issues on 32-bit platforms
#3965, ST_ClusterKMeans used to lose some clusters on initialization (Darafei Praliaskouski)
#3956, Brin opclass object does not upgrade properly (Sandro Santilli)
#3982, ST_AsEncodedPolyline supports LINESTRING EMPTY and MULTIPOINT EMPTY (Darafei Praliaskouski)
#3975, ST_Transform runs query on spatial_ref_sys without schema qualification. Was causing restore issues. (Paul Ramsey)
If compiling with PostgreSQL+JIT, LLVM >= 6 is required
Supported PostgreSQL versions for this release are: PostgreSQL 9.4 - PostgreSQL 12 (in development) GEOS >= 3.5
#1847, spgist 2d and 3d support for PG 11+ (Esteban Zimányi and Arthur Lesuisse from Université Libre de Bruxelles (ULB), Darafei Praliaskouski)
#4056, ST_FilterByM (Nicklas Avén)
#4050, ST_ChaikinSmoothing (Nicklas Avén)
#3989, ST_Buffer single sided option (Stephen Knox)
#3876, ST_Angle function (Rémi Cura)
#3564, ST_LineInterpolatePoints (Dan Baston)
#3896, PostGIS_Extensions_Upgrade() (Regina Obe)
#3913, Upgrade when creating extension from unpackaged (Sandro Santilli)
#2256, _postgis_index_extent() for extent from index (Paul Ramsey)
#3176, Add ST_OrientedEnvelope (Dan Baston)
#4029, Add ST_QuantizeCoordinates (Dan Baston)
#4063, Optional false origin point for ST_Scale (Paul Ramsey)
#4082, Add ST_BandFileSize and ST_BandFileTimestamp, extend ST_BandMetadata (Even Rouault)
#2597, Add ST_Grayscale (Bborie Park)
#4007, Add ST_SetBandPath (Bborie Park)
#4008, Add ST_SetBandIndex (Bborie Park)
Upgrade scripts from multiple old versions are now all symlinks to a single upgrade script (Sandro Santilli)
#3944, Update to EPSG register v9.2 (Even Rouault)
#3927, Parallel implementation of ST_AsMVT
#3925, Simplify geometry using map grid cell size before generating MVT
#3899, BTree sort order is now defined on collections of EMPTY and same-prefix geometries (Darafei Praliaskouski)
#3864, Performance improvement for sorting POINT geometries (Darafei Praliaskouski)
#3900, GCC warnings fixed, make -j is now working (Darafei Praliaskouski) - TopoGeo_addLinestring robustness improvements (Sandro Santilli) #1855, #1946, #3718, #3838
#3234, Do not accept EMPTY points as topology nodes (Sandro Santilli)
#1014, Hashable geometry, allowing direct use in CTE signatures (Paul Ramsey)
#3097, Really allow MULTILINESTRING blades in ST_Split() (Paul Ramsey)
#3942, geojson: Do not include private header for json-c >= 0.13 (Björn Esser)
#3954, ST_GeometricMedian now supports point weights (Darafei Praliaskouski)
#3965, #3971, #3977, #4071 ST_ClusterKMeans rewritten: better initialization, faster convergence, K=2 even faster (Darafei Praliaskouski)
#3982, ST_AsEncodedPolyline supports LINESTRING EMPTY and MULTIPOINT EMPTY (Darafei Praliaskouski)
#3986, ST_AsText now has second argument to limit decimal digits (Marc Ducobu, Darafei Praliaskouski)
#4020, Casting from box3d to geometry now returns correctly connected PolyhedralSurface (Matthias Bay)
#2508, ST_OffsetCurve now works with collections (Darafei Praliaskouski)
#4006, ST_GeomFromGeoJSON support for json and jsonb as input (Paul Ramsey, Regina Obe)
#4038, ST_Subdivide now selects pivot for geometry split that reuses input vertices. (Darafei Praliaskouski)
#4025, #4032 Fixed precision issue in ST_ClosestPointOfApproach, ST_DistanceCPA, and ST_CPAWithin (Paul Ramsey, Darafei Praliaskouski)
#4076, Reduce use of GEOS in topology implementation (Björn Harrtell)
#4080, Add external raster band index to ST_BandMetaData - Add Raster Tips section to Documentation for information about Raster behavior (e.g. Out-DB performance, maximum open files)
#4084: Fixed wrong code-comment regarding front/back of BOX3D (Matthias Bay)
#4060, #4094, PostgreSQL JIT support (Raúl Marín, Laurenz Albe)
#3960, ST_Centroid now uses lwgeom_centroid (Darafei Praliaskouski)
#4027, Remove duplicated code in lwgeom_geos (Darafei Praliaskouski, Daniel Baston)
#4115, Fix a bug that created MVTs with incorrect property values under parallel plans (Raúl Marín).
#4120, ST_AsMVTGeom: Clip using tile coordinates (Raúl Marín).
#4132, ST_Intersection on Raster now works without throwing TopologyException (Vinícius A.B. Schmidt, Darafei Praliaskouski)
#4177, #4180 Support for PostgreSQL 12 dev branch (Laurenz Albe, Raúl Marín)
#4156, ST_ChaikinSmoothing: also smooth start/end point of polygon by default (Darafei Praliaskouski)
Watch the video: PostgreSQL Tutorial: How to import Shapefile into PostGIS EN