Tag Info

Hot answers tagged

3

Put your first query in the from clause of the 2nd: something like that should work: SELECT building.id building.address FROM building, (SELECT event_point.id, event_point.geom, st_buffer(event_point.geom, 100) AS buffergeom FROM public.event_point) buffer WHERE ST_within(building.geom, buffer.buffergeom)


2

So it turns out the problem was a couple of humongous geometries in my table. One was 2GB and the other was 1 GB. This was a result of an ST_UNION I did and was not expecting that result! Killed those two records and the queries run much faster and the time to return results is more linear with larger limits. The large geometries were causing me all sorts ...


2

It's a good bet that your SRID is 4326, and that you are testing if each geometry is within 500° Latitude and/or Longitude, which is a non-sense distance. Since everything is within 500° of each other, the expected return is 1560 * 1560 = 2433600 rows. Try casting to a geography type, which uses distance units of meters (e.g., see ST_DWithin for geography ...


1

Nominatim and Mapnik/renderd use different database schemes, so you better put them in separate databases. See Can we use existing plant database for Nominatim for more details. Unfortunately, noone has ever documented the nominatim database scheme yet.


1

Yup, it's a bug. You can simplify it with: SELECT ST_AsText( ST_GeomFromGeoJSON('{"type":"LineString","coordinates":[[0,0],[1,1],[1,1],[2,2]]}')); st_astext ------------------------- LINESTRING(0 0,1 1,2 2) Which should be LINESTRING(0 0,1 1,1 1,2 2). You should file a ticket to get it fixed. If you don't have a user ID, follow these ...


1

What about the Oslandia Versioning Plugin for QGIS? http://www.oslandia.com/qgis-versioning-plugin-en.html Contrary to the promises on the website, I can't find it in the QGIS Plugin Repository.


1

@Adrian, I am really unfamiliar with the pgrouting results, however the documentation is very detailed. My answer is based on a two-step function, which will be very inneficient in SQL but [likely] produces the results. This [untested] solution will NOT optimize which is the best starting point, but will reduce the entire route network to only the edges ...



Only top voted, non community-wiki answers of a minimum length are eligible