I am trying to use the ST_Intersection function to intersect a point by city polyogn but I am having no luck (Hasura + Postgresql)
create table "public"."cities"(
geom geometry(MultiPolygon, 4326)
//other colmuns
);
then i added a row with multipolygon of my city :
INSERT INTO "public"."cities"
VALUES(ST_GeomFromText('MULTIPOLYGON(((
5.334 36.213,5.335 36.22,5.356 36.225,5.365 36.233,5.371 36.232,5.378 36.237,5.387 36.24,5.39 36.243,5.395 36.244,5.398 36.248,5.406 36.249,5.413 36.253,5.421 36.25,5.431 36.249,5.435 36.246,5.433 36.24,5.434 36.239,5.433 36.231,5.44 36.232,5.445 36.23,5.447 36.227,5.453 36.227,5.457 36.229,5.462 36.227,5.477 36.231,5.482 36.238,5.49 36.238,5.491 36.24,5.495 36.241,5.503 36.241,5.506 36.237,5.506 36.234,5.509 36.231,5.51 36.225,5.509 36.216,5.502 36.211,5.502 36.207,5.498 36.202,5.498 36.199,5.502 36.194,5.502 36.183,5.499 36.18,5.499 36.177,5.497 36.175,5.492 36.174,5.487 36.169,5.481 36.17,5.481 36.163,5.478 36.159,5.475 36.158,5.476 36.154,5.472 36.148,5.472 36.145,5.469 36.142,5.452 36.141,5.44 36.133,5.438 36.13,5.433 36.13,5.43 36.138,5.42 36.137,5.418 36.139,5.41 36.136,5.406 36.136,5.402 36.139,5.392 36.137,5.384 36.138,5.369 36.13,5.364 36.132,5.364 36.135,5.346 36.138,5.345 36.143,5.35 36.151,5.347 36.156,5.347 36.164,5.343 36.171,5.343 36.175,5.338 36.18,5.336 36.187,5.333 36.191,5.334 36.194,5.333 36.201,5.336 36.205,5.334 36.213
)))', 4326) );
But when i run this query with a Point is the center of city, i doesn't return any data.
select *
from "public"."cities"
where ST_Intersects("public"."cities"."geom", ST_GeometryFromText('POINT(36.1917 5.4235)', 4326));
UPDATE :
I stored the polygon in long-lat, but i was querying with lat-long Point, my mistake
Related
I am struggling for several hours now to query a subset of the available columns of a table as well as including a calculation in it. I know that it is not the best way to execute the calculation in the select query, but for now, I am just working on a prototype and it should be feasible for that.
I am using diesel-rs as a ORM for all my database actions in my back-end implementation. The data will be stored in a PostgresSQL server. The full table - as stored in the database - is created using the following query:
CREATE TABLE airports
(
id SERIAL PRIMARY KEY,
icao_code VARCHAR(4) NOT NULL UNIQUE, -- the official ICAO code of the airport
last_update TIMESTAMP NOT NULL, -- when were the information updated the last time?
country VARCHAR(2) NOT NULL, -- two letter country code
longitude REAL NOT NULL, -- with 6 decimal places
latitude REAL NOT NULL, -- with 6 decimal places
name VARCHAR NOT NULL -- just a human readable name of the airport
);
Running diesel migrations run generates the airports table definition and querying the database works without any issue.
Now I am trying to query a list of all airports (their ICAO code) with the corresponding coordinates as well as the distance to a supplied coordinate. Therefore, I created the following diesel-rs table! macro myself
table! {
airport_by_distance (icao_code) {
icao_code -> Varchar,
longitude -> Float8,
latitude -> Float8,
distance -> Float8,
}
}
as well as the struct corresponding to the diesel-rs definition:
#[derive(QueryableByName)]
#[table_name = "airport_by_distance"]
struct AirportByDistance {
icao_code: String,
longitude: f64,
latitude: f64,
distance: f64,
}
The following snipped - as of my understanding - should query the required information:
use diesel::dsl::sql_query;
let latitude = 4.000001;
let longitude = 47.000001;
let query_sql = format!("SELECT icao_code, longitude, latitude, (3959.0 * acos(cos(radians({lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians({long})) + sin(radians({lat})) * sin(radians(latitude)))) AS distance FROM airports ORDER BY distance;", lat=latitude, long=longitude);
let result = match sql_query(query_sql).load::<AirportByDistance>(database_connection) {
Ok(result) => result,
Err(error) => {
error!("{:?}", error);
return Err(());
}
};
Unfortunately, executing the load method, results in a DeserializationError(Custom { kind: UnexpectedEof, error: "failed to fill whole buffer" }) error.
The query which was executed was:
SELECT icao_code,
longitude,
latitude,
(3959.0 * acos(cos(radians(4.000001)) * cos(radians(latitude)) * cos(radians(longitude) - radians(47.000001)) +
sin(radians(4.000001)) * sin(radians(latitude)))) AS distance
FROM airports
ORDER BY distance;
I took it and executed it manually, but it worked flawlessly. I even tried removing the calculation and just selecting a subset of columns, but with no luck either.
Right now I am not sure what I am doing wrong. How can I fix this issue?
EDIT with the fixed code: For the ones who are interested how to code would look like after using the helpful advice of Rasmus:
The table! macro is completely gone and the data definition struct looks like this:
#[derive(Queryable)]
struct AirportByDistance {
icao_code: String,
longitude: f32,
latitude: f32,
distance: f64,
}
The code for the querying the database is as follows:
let result = match airports.select(
(
icao_code,
longitude,
latitude,
sql::<Double>(
&format!("(3959.0 * acos(cos(radians({lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians({long})) + sin(radians({lat})) * sin(radians(latitude)))) AS distance", lat=latitude_reference, long=longitude_reference)
)
)
).load::<AirportByDistance>(database_connection)
{
Ok(result) => result,
Err(error) => {
error!("{:?}", error);
return Err(());
}
};
for airport in result {
info!(
"AIRPORT: {} has {}nm distance",
airport.icao_code, airport.distance
);
}
I think the problem is that the deserializer don't know the raw types of the queried columns.
Try to use typed diesel names/values as much as possible, and explicit sql strings only where needed. And I don't think the "fake" table declaration airports_by_distance helps. Maybe something like this:
use diesel::sql_types::Double;
let result = a::airports
.select((
a::icao_code,
a::longitude,
a::latitude,
sql::<Double>(&format!("(3959.0 * acos(cos(radians({lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians({long})) + sin(radians({lat})) * sin(radians(latitude)))) AS distance", lat=latitude, long=longitue)
))
.load::<AirportByDistance>(&db)?
(Using the table! macro manually is basically just telling diesel that such a table will exist in the actual database when running the program. If that is not true, you will get runtime errors.)
I am trying to get the index position of a POINT in a MULTILINESTRING.
Here is the whole query I'm stuck with :
SELECT req.id, (dp).geom, netgeo_point_tech.id, ST_Line_Locate_Point(st_lineMerge(geom_cable), (dp).geom)
FROM (SELECT id, ST_DumpPoints(geom) as dp, geom as geom_cable FROM netgeo_cable_test ) as req
JOIN netgeo_point_tech ON ST_dwithin(netgeo_point_tech.geom, (dp).geom, 1)
ORDER BY req.id, (dp).path [ 1] ASC
The error I get is : line_locate_point : 1st arg isnt a line.
The error is due to the return of st_lineMerge() function that is returning LINESTRING but also MULTILINESTRING.
I don't get this. st_lineMerge() is supposed to return only LINESTRING.ST_LineMerge()
When I jsut try a simple query like this :
select st_astext(st_linemerge(geom)) from netgeo_cable_test
The output is :
)
I want to learn from this, so, if possible, explain to me what I'm doing wrong here, or if my approach is lacking insight.
Thanks to #JGH for the suggestion to use ST_Dump I came up with this function:
create or replace function MultiLineLocatePoint(line geometry, point geometry) returns numeric as $$
select (base + extra) / ST_Length(line)
from (
select
sum(ST_Length(l.geom)) over (order by l.path) - ST_Length(l.geom) base,
ST_LineLocatePoint(l.geom, point) * ST_Length(l.geom) extra,
ST_Distance(l.geom, point) dist
from ST_Dump(line) l
) points
order by dist
limit 1;
$$ language SQL;
I get what seems like a bug in Postgresql/Postgis. This is a completely reproducible example that demonstrates the problem:
#create a new srid for local area (formula for proj4text is taken from Quantum GIS)
INSERT INTO spatial_ref_sys (srid, auth_name, auth_srid, proj4text) VALUES (998997, 'EPSG', 998997, '+proj=tmerc +lat_0=0 +lon_0=44.55 +k=1 +x_0=2250000 +y_0=-5714743.504 +ellps=krass +towgs84=24,-123,-94,0.02,-0.25,-0.13,1.1 +units=m +no_defs ');
#create a new table for storing geometry data:
CREATE TABLE layer(
id SERIAL PRIMARY KEY,
geom geometry,
CONSTRAINT enforce_dims_geom_layer CHECK (st_ndims(geom) = 2),
CONSTRAINT enforce_srid_geom_layer CHECK (st_srid(geom) = 998997)
);
#add one polygon to the table:
INSERT INTO layer (geom) VALUES (ST_Force2D(ST_Transform(ST_GeomFromText('POLYGON((4832654.676302 7570323.2813639, 4810946.560269 7597840.6115465, 4836629.4017728 7629944.1634263, 4886772.0923279 7629944.1634263, 4902059.4979849 7591725.6492837, 4864452.4800686 7553507.1351411, 4832654.676302 7570323.2813639),(4845190.3489408 7589891.1606049, 4855585.7847875 7610376.2841853, 4876988.1527074 7604567.0700356, 4874847.9159154 7588362.4200392, 4858031.7696927 7575520.9992872, 4845190.3489408 7589891.1606049))', 3857),998997)));
#check that this polygon is valid!
SELECT ST_IsValid(ST_Force2D(ST_Transform(ST_GeomFromText('POLYGON((4832654.676302 7570323.2813639, 4810946.560269 7597840.6115465, 4836629.4017728 7629944.1634263, 4886772.0923279 7629944.1634263, 4902059.4979849 7591725.6492837, 4864452.4800686 7553507.1351411, 4832654.676302 7570323.2813639),(4845190.3489408 7589891.1606049, 4855585.7847875 7610376.2841853, 4876988.1527074 7604567.0700356, 4874847.9159154 7588362.4200392, 4858031.7696927 7575520.9992872, 4845190.3489408 7589891.1606049))', 3857),998997))) AS is_valid;
#^^^ it returns t. so, the geometry is 100% ok.
#check how it looks like in geojson format:
SELECT ST_AsGeoJSON(ST_Transform(geom, 3857))::json from layer
#^^^ Again it's ok and returns some nice geojson data
#Final step. Check ST_ApproximateMedialAxis function
SELECT ST_ApproximateMedialAxis(ST_Transform(geom, 3857)) from layer;
The final query returns an error message:
ERROR: Polygon is invalid : exterior ring and interior ring 0 have the same orientation : POLYGON((5189023446929109/1073741824 2032143182100511/268435456,5165714534831303/1073741824 31867653268373/4194304,1298322818976529/268435456 8192590163056015/1073741824,26
********** Error **********
So, all ingredients seem to be ok - formula for srid is taken from some standard widely used tool, data is inserted into the table without problems, the data is validated by ST_IsValid, geojson representation of data is also ok, but one library function still does not like something.
I have found this nice thread and came to the solution. I just have to use ST_ForceRHR Postgis function which
forces the orientation of the vertices in a polygon to follow the Right-Hand-Rule
So the right way to insert the data was:
INSERT INTO layer (geom) VALUES (ST_Force2D(ST_Transform(ST_ForceRHR(ST_GeomFromText('POLYGON((4832654.676302 7570323.2813639, 4810946.560269 7597840.6115465, 4836629.4017728 7629944.1634263, 4886772.0923279 7629944.1634263, 4902059.4979849 7591725.6492837, 4864452.4800686 7553507.1351411, 4832654.676302 7570323.2813639),(4845190.3489408 7589891.1606049, 4855585.7847875 7610376.2841853, 4876988.1527074 7604567.0700356, 4874847.9159154 7588362.4200392, 4858031.7696927 7575520.9992872, 4845190.3489408 7589891.1606049))', 3857)),998997)));
The error message is the following:
"Error: geometry contains non-closed rings"
My code is shown below:
CREATE TABLE GhanaRegions (
Id serial,
Geometry geometry DEFAULT NULL,
PRIMARY KEY (Id)
);
INSERT INTO GhanaRegions(Geometry) VALUES (ST_GeomFromText('POLYGON ((-0.024861 10.856,
-0.0250165 10.8561,
-0.0252813 10.8562,
-0.0254853 10.8563,
-0.0256633 10.8565,
-0.0259642 10.8566,
-0.0262956 10.8568,
-0.0265517 10.8572,
-0.0267774 10.8576,
-0.0270798 10.8579,
-0.0273258 10.8581,
0.02766 10.8584))'));
The first and the last points must be the same point. If they are different, the ring is not closed and the polygon cannot be built.
Solution: the first point must be used twice, as first and as last point:
INSERT INTO GhanaRegions(Geometry) VALUES (ST_GeomFromText('POLYGON ((
-0.024861 10.856,
-0.0250165 10.8561,
-0.0252813 10.8562,
-0.0254853 10.8563,
-0.0256633 10.8565,
-0.0259642 10.8566,
-0.0262956 10.8568,
-0.0265517 10.8572,
-0.0267774 10.8576,
-0.0270798 10.8579,
-0.0273258 10.8581,
0.02766 10.8584,
-0.024861 10.856
))'));
I wanna to order by distance, but I got the error
UndefinedFunction: ERROR: function st_distance(geography, geometry, numeric) does not exist
by .order("ST_Distance(lonlat, ST_Geomfromtext('#{point}'), #{radius}) ")
If I removed the above line , it works fine.
What's wrong with it ?
model
scope :nearby, lambda { |radius_in_km, lon, lat|
point = GEOG_FACTORY.point(lon, lat)
radius = radius_in_km.to_f*1000
where("ST_DWithin(lonlat, ST_GeomFromText('#{point}'), #{radius} ) ")
.order("ST_Distance(lonlat, ST_Geomfromtext('#{point}'), #{radius}) ")
}
more detail error log
PG::UndefinedFunction: ERROR: function st_distance(geography, geometry, numeric) does not exist
LINE 1: ...4028 6.530438999999999)'), 100000.0 ) ) ORDER BY ST_Distanc...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
: SELECT "weather_logs".* FROM "weather_logs" WHERE (ST_DWithin(lonlat, ST_GeomFromText('POINT (101.3034028 6.530438999999999)'), 100000.0 ) ) ORDER BY ST_Distance(lonlat, ST_Geomfromtext('POINT (101.3034028 6.530438999999999)'), 100000.0) , "weather_logs"."datetime" ASC LIMIT 20000
Completed 200 OK in 161ms (Views: 0.2ms | ActiveRecord: 5.4ms)
You are mixing geography and geometry types, that is what the error message means. If you look at the ST_DWithin docs, you will see that the signature are ST_DWithin (geometry, geometry, distance) or ST_DWithin (geography, geography, distance).
I don't know much about Ruby, so am not sure if there is a GEOM_Factory equivalent of the GEO_Factory you have used, but if you use ST_GeogFromText instead of ST_GeomFromText in your where and order by clauses, then you will be dealing with two geographies, which should solve your issue.
As your coordinates are in lat/lon, 4326, it is appropriate to use the geography datatype. If you want to know more about the practicalities of geometry vs geography, see this gis.stackexchange question.