Tag Info

New answers tagged

1

The documentation for ST_AsLatLonText explains that you can use an optional second argument to specify the format. In your case, it would be: UPDATE members SET latlong_degree = ST_AsLatLonText (the_geom, 'D°M''S"C') Note that the ' mark for the minutes has to be double quoted to avoid it just terminating the string.


0

Have a look at http://blog.cleverelephant.ca/2010/07/network-walking-in-postgis.html?m=1 (Just the opposite "walking" direction)


3

ST_StartPoint is the correct function to find single nodes at the start of a Linestring, however it does not work with MultiLinestring, so you will need to use ST_Dump to get the constituent Linestrings. If I have understood you question correctly, you then want all start points which are not also end points for more than one line, ie, points where two ...


2

If I got you right, you can achieve that by running a Python script. You can follow this workflow: Open QGIS, load a vector layer and select it (activate it) in the ToC. Observe this function: def selectByExpression(): cLayer = iface.mapCanvas().currentLayer() expr = QgsExpression( "\"COD_DANE\"=13" ) it = cLayer.getFeatures( ...


1

I've included a screenshot to show where the function is in the Configure shortcuts option:


0

I may be able to weigh in here, as I did a similar cemetery project a few years back. It is not too difficult to use a python script to pass variables through to an SQL statement to select certain graves, but it can become very frustrating if you are unfamiliar with the syntax. It is a good idea to search this site for hints like How to include variable in ...


1

PostgreSQL doesn't use indexes for functions, it uses indexes for operators only. What happens is function inlining. ST_INTERSECTS is defined as: CREATE OR REPLACE FUNCTION ST_Intersects(geom1 geometry, geom2 geometry) RETURNS boolean AS 'SELECT $1 && $2 AND _ST_Intersects($1,$2)' LANGUAGE 'sql' IMMUTABLE; And so the query gets rewritten to use ...


2

Note that planners have difficulty with subqueries, and your example can be rewritten without subqueries. A flattened query should look like this: SELECT A.* FROM osm_addr2 AS addr, osm_addr2 AS POI WHERE POI.osm_id=-332537 AND ST_Intersects(addr.geometry, POI.geometry); There's a relevant example in the manual (last two SQL examples), where a subquery is ...


0

Judging by the cost and quantity of rows estimated to be returned, the spatial index wasn't necessary. At least the optimizer didn't think it was and chose a seq scan instead. Is it running slow? How may rows do you expect back? How many rows are in the table altogether? Sorry if I overlooked that in your question but sometimes a full scan is faster. ...


1

I have found that rearranging the query so that the sub-query is at the same level as the initial select, essentially a Cartesian product, but then using the where clause to restrict the records read, will cause the indexes to be used and avoid a full table scan. SELECT * FROM osm_addr2 AS addr, (SELECT geometry FROM osm_addr2 WHERE osm_id=-332537) ...


1

I recommend two Queries, since the results from focnetworkpart and node are not related in anyway (at least according to your desciption). The Problem you will or already ran into is the combination of both results. So you are better of first asking one table for results and then the other. Then you can work with both results. Also be aware that ST_DWithin ...


0

Some of ArcSDE operations are pretty heavy and it is mentioned in the documentation. ESRI is improving it. Check out cursors for example (classical vs arcpy.da). One big con I can think right off the bat is that how you manage mutual exclusion and load balancing on your connection(s). Also, you may run into transactional issues, locks, etc. Note that ...



Top 50 recent answers are included