Tag Info

New answers tagged

0

To follow up, what I did was to: Keep the original SQL query (easier to understand/maintiain) Create a temp table Insert values into temp table, using ST_MakePoint($stop_lon, $stop_lat) and geom to handle the lat/long values Use the following SQL to create the geoJSON file SELECT row_to_json(fc) FROM ( SELECT 'FeatureCollection' As type, ...


0

admin.site.register(Poly, admin.GeoModelAdmin) or admin.site.register(Poly, admin.OSMGeoAdmin) # for openstreet map


1

You can use the function ST_SRID to get the spatial reference identifier. To get the distance between points you can use the function ST_DISTANCE.


2

You have pretty much suggested the answer to your own question already, which is that you don't have any indexes. I would suggest that you convert your lat/lon columns to a geography (point) data type, add a spatial index, and rewrite the query to use ST_DWithin, which uses a spatial index, if available, and works with geometries or geographies. ALTER ...


0

I really think that joining on 1 = 1 is not a good idea... Try making your select statement smaller by using ST_DWithin(geom1, geom2, 300) , which is definitely faster than ST_Distance_Sphere() Build indexes! Can you share the data? A portion at least. UPDATE: I guess it would be useful to narrow down the join with distance condition before the join ...


0

Hope it helps someone: The point was that tinyows (version 1.0.0) when adding a new feature when getting a "insert" transaction request, adds a random string as GID. Now GID is either an integer or a biginteger, and defaults to NEXTVAL(sequence) in the Postgres/Postgis table. The GID that tinyows created was too big (out of range). Tinyows works fine ...


0

a) You are using the build-in postgresql's geometry data type and not Postgis Point data type. I would follow the production specifications. There are some VERY good reasons to switch the production db to use postgis datatypes but in production enviroments that is not always fearsable. b) you can cast from point to geometry/geography and vice versa select ...


0

The basis for the PostGIS geographic type is a sphere. The basis for the PostGIS geometry type is a plane. (same link) Thus, when you run ST_Buffer on a EPSG:4326 geometry, the output is given in degrees of lat/lon. On the other hand, when you do the same for EPSG:4326 geography, you get result in meters. What you can do (besides using geography type) is ...



Top 50 recent answers are included