ST_Difference correct syntax - postgis

I'm trying to run ST_Difference on 3D geometries, I have 2 overlapping cubes, cube1 and cube2.
CREATE TABLE cube_diff AS
SELECT ST_Difference(cube1.geom, cube2.geom) AS geom
FROM cube1, cube2
3D Intersection works fine:
ST_3DIntersection(cube1.geom,cube2.geom) AS geom
But ST_Difference complains saying I'm working with Polyhedral surfaces, I used ST_IsSolid, it returns true.

Related

problem in st_contains postgis vie postgres

i am new in postgis and have a problem when using st_contains in postgressql.
i have two table :
one table with multilinestring type and srid 3857 like this :
'MULTILINESTRING((5422968.66785559 3677150.09505449,5422968.65492085
3677150.0886859,5422952.17411073 3677141.94577852,5422933.98180744 3677132.88239635,5422908.89206302 3677120.3831169,5422889.41793598 3677110.66168418,5422860.41342641 3677096.31330017,5422843.29303681 3677087.88278276),(5422968.4135149 3677150.59358815,5422980.01582934 3677156.57635076,5422990.22979481 3677161.61762274,5423006.30129137 3677169.56131558))'
and another table Points type and srid 3857 like this :
'POINT(48.6977500915527 31.3106079101563)'
i use from st_buffer for first table which is multilinestring geom type and expect find any point from table 2 that is inside this buffer
when i use st_contains does not return any row , what is the problem ? although both srid are 3857
select ST_X(P.geom) lng , ST_Y(P.geom) lat from public."Zone" A
inner join public."Points" P on ST_Contains(ST_Buffer(A.geom, 100), P.geom)
From:
https://postgis.net/docs/ST_X.html
And
https://postgis.net/docs/ST_Y.html
It says that the geom inside st_X and st_Y must be a point, or NULL if not available.
Can you try just running
select A.geom as lines, P.geom as point from public."Zone" A
inner join public."Points" P on ST_Contains(ST_Buffer(A.geom, 100), P.geom);
To see if it returns anything ?
The point is not in 3857 but rather in 4326. You would need to transform it to 3857 first
select st_asText(st_transform(st_GeomFromText('POINT(48.6977500915527 31.3106079101563)',4326),3857));
st_astext
------------------------------------------
POINT(5421008.74296974 3673153.53251071)
That being said, it is more reliable to use st_dwithin rather than st_buffer.

Postgis query to update linestring

while executing this query i am getting error
UPDATE treedetailsentered
set geom_line=st_geomfromtext('LineString(('||longitude||' '||latitude||','||lon2||' '||lat2||'))', 4326);
error
ERROR: parse error - invalid geometry
HINT: "LineString((7" <-- parse error at position 13 within geometry
********** Error **********
this is how i created column in table for the linestring
ALTER TABLE public.treedetailsentered
ADD COLUMN geom_line geometry(LineString, 4326)
It's hard to tell what the exact problem is without knowing what type longitude, latitude have, but my guess is that you're not forming a proper string.
My advice is to debug this by first creating a proper text via a query that's simpler:
select 'LineString(('||longitude||' '||latitude||','||lon2||' '||lat2||'))'
Depending on what types you have, you might have to do some conversions, like this:
select 'LineString(('||longitude::text||' '||latitude::text||','||lon2::text||' '||lat2::text||'))'
If you already have texts, make sure that the numbers are properly formatted. Floats are expected to have a dot decimal separator for example.
I have added an extra bracket i removed that it worked for me.
UPDATE treedetailsentered set geom_line=ST_GeomFromText('LINESTRING(' || longitude || ' '||latitude||','||lon2||' '||lat2||')', 4326);

Issues using mdx generated from PivotTable

I recently used excel to connect to analysis services and generate a mdx code that was used to query the cube. The code is shown below. The code was also verified using sql profiler. However when I go to analysis services and browse the cube and put in the cube in management studio, I get errors. Please let me know if the code can be fixed. This code is exactly what i need for my requirements so if there are any modifications please replace it within the cube itself.
Code
SELECT NON EMPTY Hierarchize(DrilldownMember(CrossJoin({
[ColorsDim].[PrimeColor].[All], [ColorsDim].[PrimeColor].[PrimeColor].AllMember},
{([ColorsDim].[SecondColor].[All]) }), [ColorsDim].[PrimeColor].[PrimeColor].AllMember,
[ColorsDim].[SecondColor])) DIMENSION PROPERTIES PARENT_UNIQUE_NAME
,HIERARCHY_UNIQUE_NAME ON COLUMNS
,NON EMPTY Hierarchize({DrilldownMember({
[ColorsDim].[Color_id].[All] },,, INCLUDE_CALC_MEMBERS) }) DIMENSION PROPERTIES
PARENT_UNIQUE_NAME
,HIERARCHY_UNIQUE_NAME ON ROWS FROM [Model]
WHERE ([Measures].[Number of records in ColorDim]) CELL PROPERTIES VALUE
,FORMAT_STRING
,BACK_COLOR
,FORE_COLOR
,FONT_FLAGS
Error
Query Preparation failed.
Additional information
The query cannot be prepared: The query must have at least one axis. The first axis of the query should not have mulitple hierarchies, nor should it reference any dimension other than the measures dimension..
Parameter name: mdx (MDXQueryGenerator)
Desired Output
The following query shows the desired output:
Select non empty
[ColorsDim].[PrimeColor].children *
[ColorsDim].[SecondColor].children
on 0
, non empty
[ColorsDim].[Color_id].children
on 1
from [model]
where [Measures].[Number of records in ColorDim];
The measure in the query is a count of rows for that particular dimension
Well the error message you've provided looks to me like an SSRS error message.
If you open SSMS with a connection to the cube and then open an mdx query the query should run ok.
Reformatting the query so we can see more clearly what is happening gives this:
SELECT
NON EMPTY
Hierarchize(
DrilldownMember(
CrossJoin(
{[ColorsDim].[PrimeColor].[All]
, [ColorsDim].[PrimeColor].[PrimeColor].AllMember}
,{([ColorsDim].[SecondColor].[All]) }
)
, [ColorsDim].[PrimeColor].[PrimeColor].AllMember
, [ColorsDim].[SecondColor]
)
) DIMENSION PROPERTIES PARENT_UNIQUE_NAME
,HIERARCHY_UNIQUE_NAME ON COLUMNS
,NON EMPTY
Hierarchize(
{
DrilldownMember(
{[ColorsDim].[Color_id].[All] }
,,, INCLUDE_CALC_MEMBERS
)
}
)
DIMENSION PROPERTIES PARENT_UNIQUE_NAME
,HIERARCHY_UNIQUE_NAME ON ROWS
FROM [Model]
WHERE ([Measures].[Number of records in ColorDim])
CELL PROPERTIES VALUE
,FORMAT_STRING
,BACK_COLOR
,FORE_COLOR
,FONT_FLAGS
Excel adds a lot of boilerplate code so we can get rid of the cell and dimension properties, I suspect hierarchize is not needed, and the crossjoin can be replaced with the simple * operator, to give this:
SELECT
NON EMPTY
DrilldownMember(
[ColorsDim].[PrimeColor].[All]
* [ColorsDim].[PrimeColor].[PrimeColor].AllMember
,{([ColorsDim].[SecondColor].[All])}
)
, [ColorsDim].[PrimeColor].[PrimeColor].AllMember
, [ColorsDim].[SecondColor]
)
ON 0
,NON EMPTY
DrilldownMember(
{[ColorsDim].[Color_id].[All] }
,,, INCLUDE_CALC_MEMBERS
)
ON 1
FROM [Model]
WHERE [Measures].[Number of records in ColorDim];
If you want to use this in SSRS then you will need to re-write it so that COLUMNS (or 0) only uses the dimension Measures!
To make it so that ssrs is happy enough you could do this:
WITH
MEMBER [Measures].[Green_YellowGreen] AS
(
[ColorsDim].[PrimeColor].[PrimeColor].[Green],
[ColorsDim].[PrimeColor].[SecondColor].[Yellow-Green],
[Measures].[Number of records in ColorDim]
)
MEMBER [Measures].[Green_BlueGreen] AS
(
[ColorsDim].[PrimeColor].[PrimeColor].[Green],
[ColorsDim].[PrimeColor].[SecondColor].[Blue-Green],
[Measures].[Number of records in ColorDim]
)
SELECT
NON EMPTY
{[Measures].[Green_YellowGreen], [Measures].[Green_BlueGreen] }
ON 0
, NON EMPTY
[ColorsDim].[Color_id].children
ON 1
FROM [model];

PostgreSQL query within PostGIS function

I am trying to run the following PostGIS query:
select ST_distance_spheroid(
ST_GeomFromText('POINT(
(select AsText(location) from test where name="EGMC")
)', 4326),
ST_GeomFromText('POINT(
(select AsText(location) from test where name="EGDY")
)', 4326),
'SPHEROID["WGS_1984",6378137,298.257223563]'
);
but keep getting an error:
ERROR: parse error - invalid geometry
HINT: "POINT(
(s" <-- parse error at position 9 within geometry
I'm happy that I know what the error means, I just don't know how to go about achieving what I want to do. I don't want to manually specify the location, it's stored in the database! I know the name of the place, so I want to get it's location by looking it up. How should I be doing this? Also, it seems a bit unnecessary to convert to a string to convert back, what else can I do?
If I can do this without having to specify variables that would be great.
Thanks.
You are mixing SQL and WKT, which are not the same. Furthermore, you don't need to recreate geometries that already exist. Query the existing geometries instead:
select ST_distance_spheroid(g1.location, g2.location, 'SPHEROID["WGS_1984",6378137,298.257223563]')
from test g1, test g2
where g1.name = "EGMC" and g2.name = "EGDY";

SQL Server 2008 Geometry not working?

I'm having an issue with SQL Server 2008 and the geometry functions. I'm trying to create non-overlapping shapes using the STDifference function... but it does not seem to be working 100% of the time.
Here is all the sample code to demonstrate the issue. Anybody have any idea to make these non-overlapping polygons? (except "don't make your polygons so complex")
-- create our Geometry polygons.
DECLARE #Geo1 Geometry, #Geo2 Geometry;
SET #Geo1 = geometry::STGeomFromText('POLYGON ((-79725887.5234375 42951274.765625, -79699548.921875 42991827.84375, -79695546.375697568 42997990.498925969, -79695559.967852488 42998690.733179785, -79696152.0625 43029192.375, -79715247.75 43051708.75, -79802181.8984375 43020797.71875, -79806253.6640625 43018621.6953125, -79810436.03125 43014767.046875, -79825837.5 43000572.375, -79830640.625 42973672.03125, -79832936.7265625 42960812.4296875, -79725887.5234375 42951274.765625))',0);
SET #Geo2 = geometry::STGeomFromText('POLYGON ((-79863430.6875 42937209.4375, -79850399.0625 42940068.75, -79850394.9375 42940069.625, -79845320.6875 42946082.625, -79843216.25 42948576.375, -79832949.125 42960743, -79814909.939453125 43061773.556640625, -79817218.30078125 43060262.947265625, -79823496.6875 43056154.3125, -79867800.5 43027161.5625, -79871834.50390625 43024521.70703125, -79875660.228515625 43022018.123046875, -79875666.8125 43022013.8125, -79875674.536313191 43022008.760254942, -79875676.408203125 43022007.53515625, -79875677.236328125 43022006.994140625, -79875718.458984375 43021980.017578125, -79875728.506891936 43021973.442301653, -79881723.017578125 43018050.58984375, -79882437.0625 43017583.3125, -79882585.375 43017486.25, -79884466.9375 43016254.9375, -79884550.875 43016200, -79886514.3125 43014915.125, -79887785.5 43014083.25, -79887790.4375 43014080, -79887793.125 43014078.26953125, -79887807.171875 43014069.076171875, -79887825.568359375 43014057.03515625, -79887831.322335 43014053.269705132, -79888029.5 43013923.5625, -79890094.5625 43012572.1875, -79934236.875 42983685.125, -79863430.6875 42937209.4375))',0);
-- A quick test so you can see them
SELECT #Geo1, 'Geo1' as MyName UNION ALL SELECT #Geo2, 'Geo2' as MyName;
-- how do they compare initially?
SELECT
#Geo1.STTouches(#Geo2) as 'Touches'
,#Geo1.STOverlaps(#Geo2) as 'Overlaps'
,#Geo1.STIntersects(#Geo2) as 'Intersects'
-- try to make them NOT overlap or intersect
SET #Geo1 = #Geo1.STDifference(#Geo2);
SET #Geo2 = #Geo2.STDifference(#Geo1);
-- Now, how do they compare?
SELECT
#Geo1.STTouches(#Geo2) as 'Touches'
,#Geo1.STOverlaps(#Geo2) as 'Overlaps'
,#Geo1.STIntersects(#Geo2) as 'Intersects'
-- what does the intersection look like?
SELECT #Geo1.STIntersection(#Geo2).STAsText();
This is the final select result:
MULTIPOLYGON (((-79831832.015625 42966999.5078125, -79830502.34765625 42974446.45703125, -79830181.430394545 42976243.79133676, -79830220.96484375 42976022.375, -79831832.015625 42966999.5078125)), ((-79832481.0538819 42963364.484146826, -79832328.75390625 42964217.45703125, -79831832.015625 42966999.5078125, -79832481.0538819 42963364.484146826)))
Not an answer, just an observation... I get different results if I introduce two new variables for the two differences.
-- create our Geometry polygons.
DECLARE #Geo1 Geometry, #Geo2 Geometry, #Geo3 Geometry, #Geo4 Geometry;
SET #Geo1 = geometry::STGeomFromText('POLYGON ((-79725887.5234375 42951274.765625, -79699548.921875 42991827.84375, -79695546.375697568 42997990.498925969, -79695559.967852488 42998690.733179785, -79696152.0625 43029192.375, -79715247.75 43051708.75, -79802181.8984375 43020797.71875, -79806253.6640625 43018621.6953125, -79810436.03125 43014767.046875, -79825837.5 43000572.375, -79830640.625 42973672.03125, -79832936.7265625 42960812.4296875, -79725887.5234375 42951274.765625))',0);
SET #Geo2 = geometry::STGeomFromText('POLYGON ((-79863430.6875 42937209.4375, -79850399.0625 42940068.75, -79850394.9375 42940069.625, -79845320.6875 42946082.625, -79843216.25 42948576.375, -79832949.125 42960743, -79814909.939453125 43061773.556640625, -79817218.30078125 43060262.947265625, -79823496.6875 43056154.3125, -79867800.5 43027161.5625, -79871834.50390625 43024521.70703125, -79875660.228515625 43022018.123046875, -79875666.8125 43022013.8125, -79875674.536313191 43022008.760254942, -79875676.408203125 43022007.53515625, -79875677.236328125 43022006.994140625, -79875718.458984375 43021980.017578125, -79875728.506891936 43021973.442301653, -79881723.017578125 43018050.58984375, -79882437.0625 43017583.3125, -79882585.375 43017486.25, -79884466.9375 43016254.9375, -79884550.875 43016200, -79886514.3125 43014915.125, -79887785.5 43014083.25, -79887790.4375 43014080, -79887793.125 43014078.26953125, -79887807.171875 43014069.076171875, -79887825.568359375 43014057.03515625, -79887831.322335 43014053.269705132, -79888029.5 43013923.5625, -79890094.5625 43012572.1875, -79934236.875 42983685.125, -79863430.6875 42937209.4375))',0);
-- A quick test so you can see them
SELECT #Geo1, 'Geo1' as MyName UNION ALL SELECT #Geo2, 'Geo2' as MyName;
-- how do they compare initially?
SELECT
#Geo1.STTouches(#Geo2) as 'Touches'
,#Geo1.STOverlaps(#Geo2) as 'Overlaps'
,#Geo1.STIntersects(#Geo2) as 'Intersects'
-- try to make them NOT overlap or intersect
SET #Geo3 = #Geo1.STDifference(#Geo2);
SET #Geo4 = #Geo2.STDifference(#Geo1);
-- Now, how do they compare?
SELECT
#Geo3.STTouches(#Geo4) as 'Touches'
,#Geo3.STOverlaps(#Geo4) as 'Overlaps'
,#Geo3.STIntersects(#Geo4) as 'Intersects'
-- what does the intersection look like?
SELECT #Geo3.STIntersection(#Geo4).STAsText();
Compare:
Touches Overlaps Intersects
1 0 1
Final Select:
MULTIPOINT ((-79830220.96484375 42976022.375), (-79831832.015625 42966999.5078125))
I suspect this is due to the method/precision with which SQL Server performs spatial calculations. For operations like STIntersection() etc, SQL Server rounds the supplied float coordinate values to a 27 bit integer grid. This can introduce slight distortions to the coordinates returned as the result of spatial operations.
In your case, your coordinate values are large, which means that the fixed size integer grid must be made quite coarse to accommodate the full range of data. The relative difference between the intersecting coordinates that you're trying to remove, however, is very small. When snapped to this coarse grid, SQL Server is unable to correctly identify the area of intersection.
See here for a explanation, and also a suggestion that this situation has been improved in SQL Server Denali:
https://connect.microsoft.com/SQLServer/feedback/details/580254/spatial-operations-are-done-with-a-low-precision-causing-troubles-in-the-returned-data
As pointed out by Joe Stefanelli, your polygons don't technically overlap but they do intersect. The reason is that if you cut a hole out of one polygon using a smaller polygon, the smaller polygon will not overlap the new polygon but it will intersect it along the edge of the cut. It isn't like a table saw that removes some material along the edge of the cut. I could not include the code because SO is having a problem with certain SQL statements and blocks the post.
SEE REFERENCE A in image
If you would like it not to overlap OR intersect, you can create your own sawblade effect. Apply a very small buffer around the smaller of the geometries when using it in the STDifference() function.
SEE REFERENCE B in image
I know this post is old but it does seem pertinent still for those of us who will still be on 2008 for a while.

Resources