I am attempting to store a LINESTRING using PostGIS into a column of type geography(LINESTRING, 4326). Here is my insert statement:
INSERT into routes (line) VALUES (st_linefromtext('LINESTRING(-35.3350743932 149.084182978,-35.3350306311 149.085041285)', 4326));
But when I run a query to get the line back out of the database.
SELECT st_astext(line) from routes;
Result:
LINESTRING(-35.3350743932 30.915817022,-35.3350306311 30.914958715)
The latitude coordinates come out completely differently from how I inputted them. Can anyone point out to me why this would be?
I am new to PostGIS - I think I must be missing something about the storage and retrieval of 4326 data. Any help appreciated.
Related
I have two tables with geometry data. One table has MULTIPOLYGON geometry in non-standard srid and another has POINT geometry in 4326. I have a spatial_ref_sys table with a correct description for my srid. Then I want to use st_contains for geometry from these tables. I use st_transform to convert geometry from one table to srid from another, but the function returns geometry under Africa (all geometry is on the territory of Europe). Also, I want to admit that I use proj description from QGIS, and in this program, all works correctly. I use PostGIS 3.2. Here is my code for st_contains:
select st_contains(st_transform(geom_multipolygon_in_4326, SRID_from_another_table), geom_point_in_non_standart_srid);
Here is my proj:
+proj=tmerc +lat_0=0 +lon_0=30 +k=1 +x_0=-10000 +y_0=-5540000 +ellps=krass +towgs84=23.92,-141.27,-80.9,0,0.35,0.82,-0.12000000004786 +units=m +no_defs
However, when I use PostGIS 2.2 all works correctly with an identical proj description. I don't understand what the problem is. Maybe someone can help me, because I only found a solution by creating a layer in qgis and then importing it into the database, but this is not a solution for me, because the point geometry is formed through a query to Google and I still need to transform it using st_transform.
i'm working with postgreSQL with converting long/lat to point and also want to make line with that point
select bs1.rental_shop_name,
bs1.lon,
bs1.lat,
bs2.rental_shop_name,
bs2.lon,
bs2.lat,
count(*),
ST_MakeLine(ST_MakePoint(bs1.lon, bs1.lat), ST_MakePoint(bs2.lon, bs2.lat))
from bikeuser as bu
join bikestation as bs1 on bs1.rental_shop_code = bu.rental_shop_code
join bikestation as bs2 on bs2.rental_shop_code = bu.return_shop_code
group by bs1.rental_shop_name,
bs1.lon,
bs1.lat,
bs2.rental_shop_name,
bs2.lon,
bs2.lat,
ST_MakeLine(ST_MakePoint(bs1.lon, bs1.lat), ST_MakePoint(bs2.lon, bs2.lat))
order by count desc limit 40
but result is failed and msg is
SQL state: 42883 the st_makepoint does not exist and also have to use explicit converter
also i tested with simple form like this.
SELECT ST_MakePoint(-71.1043443253471, 42.3150676015829);
BUT ITS SAME RESULTS...
Just ST_MakePoint is not enough with lat long. You have to set SRID of the geometry as well. If the data comes from WGS84(which usually is the case with lat long), you need to apply ST_SetSRID on the geometry.
ST_MakeLine(ST_SetSRID(ST_MakePoint(bs1.lon, bs1.lat),4326), ST_SetSRID(ST_MakePoint(bs2.lon, bs2.lat),4326))
You should take into account your own data SRID.
I am new to sql, and attempting to use it to speed up spatial analysis on a set of ~1.2 million trips from a csv that contains the lat and lon for pickup and dropoff points.
What I am trying to do in plain English is:
select all trips that start in the area of interest (loaded into my database as a shapefile) into one table
select all trips that end in the area of interest into another
-perform a spatial join between these points and a shapefile of census tracks (which contains neighborhood names)
count by neighborhood name to list the most frequent origins/destination of trips to/ from the area of interest.
The code I am working with is below (If its helpful, NTA or neighborhood tabulation area, is the neighborhood name which I want to display in my table at the end of this operation) :
--Select all trips that end in project area
SELECT *
INTO end_PA
FROM trips, projarea
WHERE ST_Intersects(trips.dropoff, projarea.geom);
--for trips that end in project area - index by NTA of pick up point
ALTER TABLE end_PA ADD COLUMN GID SERIAL;
CREATE TABLE points_ct_end AS
SELECT nyct2010.ntacode as ct_nta, end_PA.gid as point_id
from nyct2010, end_PA WHERE ST_Intersects(nyct2010.geom , end_PA.pickup);
--Count most common NTA
--return count for each NAT as a csv
copy(
select count(ct_nta) from points_ct_end
group by ct_nta
order by count desc)
to 'C://TaxiData//Analysis//Trips_Arriving_LM.csv' DELIMITER ',' CSV HEADER;
However, I am having problems from the very start - ST_Intersects does not return any points within the area of interest!
Troubleshooting solutions I have tried thus far:
My first thought is that the points weren't in the correct SRID. When I created the 'dropoff' point I set the SRID to 4326. I tried both using ST_SetSRID to change the projection of both data sets to 4326, and manually re projecting the shapefiles to 4326 in ArcMap - but neither worked.
I plotted a small sample of the points from the 'trips' data set in Arc Map to ensure they were correctly projected and overlapping with the ProjArea shapefile. They are.
I imported the multipoint shapefile this created into my geo database to test if that worked with ST_Intersects. Nope.
I tried using ST_Within. This threw the error message:
ERROR: function st_within(character varying, geometry) does not exist
....
HINT: No function matches the given name and argument types. You
might need to add explicit type casts.
I am using Big SQL and postgres
Thanks!!
My first thought is that the points weren't in the correct SRID. When I created the 'dropoff' point I set the SRID to 4326. I tried both using ST_SetSRID to change the projection of both data sets to 4326, and manually re projecting the shapefiles to 4326 in ArcMap - but neither worked.
ST_SetSRID doesn't change the projection (reproject). It just changes the internal representation. This can totally screw everything up if the previous SRID matched the input data. You likely wanted ST_Transform().
There isn't enough information here to trouble shoot this problem. However, we can answer this...
ERROR: function st_within(character varying, geometry) does not exist
This simply means the first argument is not a geometery. Of course, we can't do anything with that at all because we don't have your query that you tried with ST_Within().
Your syntax for ST_Intersects() looks to be right. But, there simply isn't enough information provided to help. Show some schema and sample data.
I started to use PostGIS recently and i have a table with a column longitudes and a column latitudes.
I want to know if it's possible (and how) to put these lon/lat columns informations into the new geographical column (with possibly ST_GeogFromText)
I already tried something like :
UPDATE my_table SET geo = ST_GeogFromText('SRID=4267;POINT(lon.my_table lat.my_table)');
Thanks for your reading and you help.
ST_GeogFromText takes a formatted text of EWKT, which is a lossy and inefficient method.
Try using ST_MakePoint instead:
UPDATE my_table SET geo = ST_SetSRID(ST_MakePoint(lon, lat), 4267)::geography;
i am trying to insert LineStrings to a local Postgres/PostGIS-database. I use Python 2.7, psycopg2 and ppygis.
Every time when i make a loop-input, only a few records were inserted into the table. I tried to find out the problem with mogrify, but i see no failure.
polyline = []
for row in positions:
lat = row[0]
lon = row[1]
point = ppygis.Point(lon, lat, srid=4326)
polyline.append(point)
linestring = ppygis.LineString(polyline, srid=4326)
self.cursor.execute("BEGIN")
self.cursor.execute("INSERT INTO gtrack_4326 (car, polyline) VALUES (%s,%s);", ("TEST_car", linestring))
self.cursor.execute("COMMIT")
The use of execute.mogrify results in Strings like this:
INSERT INTO gtrack_4326 (car,polyline) VALUES ('TEST_car', '0102000020e610000018000000aefab72638502940140c42d4d899484055a4c2d84250294056a824a1e3994840585b0c795f50294085cda55df1994840edca78a57650294069595249f8994840ec78dd6cbd502940828debdff5994840745314f93f5129407396fecaef994840e1f6bafbd25129404eab329de7994840da588979565229407a562d44e2994840ebc9fca36f522940c2af4797ed9948403bd164b5af5229407a90f9dbf99948407adbf1cb05532940818af4ec039a484062928087585329402834ff9e0e9a4840e8bb5b59a2532940b1ec38341b9a4840dcb28d89de532940afe94141299a484084d3275e0a54294019b1aab9379a484080ca42853454294053509b82469a48408df8043f6054294063844b22569a48406d3e09c7875429406dfbc33b659a4840aa5a77989b542940c20e08196d9a48401b56a7b9cb542940a0a0b9f3699a4840cf2d742502552940192543e9669a484045ac0f351b552940fdb0efd46d9a48406891ed7c3f552940450a0a28799a4840d0189c77525529405f7b6649809a4840');
But if i look into the Database, i see a lot of records without geometry-data in the second column. I did not understand why mogrify shows data in each column and in the DB there is in nearly 50 % of the table no data in the geometry-column.
First, psycopg2 does its own transaction management, so you should generally write:
self.cursor.execute(
"INSERT INTO gtrack_4326 (car, polyline) VALUES (%s,%s);",
("TEST_car", linestring)
)
self.conn.commit()
See the psycopg2 docs.
Second, consider loading data in batches with COPY. See COPY in the psycopg2 docs.
Also consider setting log_statement = 'all' in postgresql.conf and a suitable log_line_prefix then restarting the PostgreSQL server. Examine the logs and see if you can tell what's doing the bogus inserts.
If practical, add a CHECK and/or NOT NULL constraint to the geometry column so that any incorrect INSERTs will fail and report an error to the program doing the insert. This might help you diagnose the problem.
How did you determine that 50% of the rows have no geometry data? I'll warn anyone using clients like pgAdminIII show a blank cell if it contains too much data, so it appears to be NULL, when it isn't. You can also directly view the GIS data in a program like Quantum GIS.
With an SQL client, a better diagnostic to determine if a linestring is really there is to get the number of points in the linestring:
SELECT car, ST_NumPoints(polyline) FROM gtrack_4326;
If the numbers are empty, then your assessment is correct that they are empty. Otherwise, the data are too large to display in your client application.