Tag Info

Hot answers tagged

10

'foo' is the name that has been assigned to the sub-selection. It has no function other than being syntactically necessary - a sub-selection in PostgreSQL must have a name assigned to it, but it does not matter what the name is. 'foo' was likely chosen because it is a common meaningless placeholder word used by programmers, similar to 'lorem ipsum' used by ...


3

Your data looks like it's Mercator (big negative X's). I'll assume web mercator, but that could be wrong, and may lead to meter-level inaccuracies (if it's "real" mercator, use 3395). shp2pgsql -c -d -D -W LATIN1 -s 3857 -I 'path/to/shapefile.shp' my_table | psql -d mydb Now flip the coordinates to geographics inside the database ALTER TABLE my_table ...


3

Your Line ... WHERE ST_geometrytype(geom) = ST_Point; Indicates that ST_Point is a column since it is not in quotes. I see here also a comment from @Vince that is saying basically the same thing that I am. Since ST_Point is not quoted in your expression is is trying to evaluate what is in ST_geometrytype(geom) against another field/column and it can't ...


2

You should use osm2pgrouting to import the osm data into you DB, it's a command line tool that will automatically create the appropriate graph for pgrouting. http://www.pgrouting.org/docs/tools/osm2pgrouting.html


2

The raster constraints are used to ensure that all rasters have the same SRID, pixel dimensions, pixel types and alignments, as you can see from RT_AddRasterConstraints docs. These are important if you want to do intersections, resampling, unions, reprojections, or vector-raster overlays, etc, as I'm sure you know. I was surprised that you could add an ...


2

Following functions exist in Oracle: SDO_CS.MAP_EPSG_SRID_TO_ORACLE SDO_CS.MAP_ORACLE_SRID_TO_EPSG So SELECT SDO_CS.MAP_ORACLE_SRID_TO_EPSG(xxx) FROM dual; yields: 90112 -> null 327680 -> 31300 8307 -> 4326 (Weird that 90112 isn't mapped...)


2

There is an answer on StackOverflow that gives a mathematical, but not a Postgres answer. Translating to Postgres/Postgis, you could try something like this: select sum(st_x(pt)*weight)/sum(weight) as cx from weighted_points; select sum(st_y(pt)*weight)/sum(weight) as cy from weighted_points; Or if you want a point back, then, select st_makepoint(x.cx, ...


2

I think the best approach is to go with Mapserver or Geosever (since you are new, Geoserver will look a lot easier) Once you set a WMS service with geoserver, you can add the resulting WMS to your OpenLayers project. Geoserver automatically returns only the information in the extent of the current view, also you can set the range of visible scales on your ...


2

It looks like you're trying to get a unique integer field for QGIS to use as a key. I've had luck using the row_number window function for this. The basic syntax is: SELECT row_number() OVER () As vid, ... That will give each row a sequential integer starting with 1.


1

SELECT ST_X(pts.geom) as lon, ST_Y(pts.geom) as lat, poly.attribute FROM points pts, polygons poly WHERE ST_Intersects(poly.geom, pts.geom); where it is assumed that the attribute you want from the polgons table is called attribute. For non-trivial table sizes, you will want a spatial index on the geometry columns of polygons/points tables.


1

Select points.*, polygons.* from points inner join polygons on st_intersects(points.geom,polygons.geom);


1

Figured it out. I needed to add in: map.aspect_fix_mode = mapnik.Map.ASPECT_RESPECT; before: map.extent = bbox;


1

I would highly recommend a literature search before embarking on an IDW approach. A colleague of mine has a few papers on dual-phase sampling of cellular signals using Kriging. Because cellular signals are a highly nonstationary spatial process, an IDW approach is not appropriate. Whereas Kriging can have a model term to account for 2nd order effects as well ...


1

When you use OSM data for pgRouting, then you need to use special import tools. This will automatically solve your problem. To get started I highly recommend you the pgRouting workshop, because it will exactly guide you to get pgRouting work with OSM data: http://workshop.pgrouting.org/


1

You need to get the data from the server in geoJSON format. I can get you an example in PHP if you want, but I think there are plenty examples around. Then in Javascript, you can do something like this: $(document).ready(function(){ setInterval(function() { $.get("datasource.php", function (data) { if ( !data.error ) { ...


1

If you are particularly interested in using meters as the unit for the search, you can use geography data types instead of geometry types. All geography based calculations return values in meters. Also, ST_DWITHIN is designed for this type of queries: select * from zones z where ST_DWITHIN(Geography(ST_Transform(z.geom,4326)), ...


1

What are looking for is an OpenLayers strategy. You do not use this directly, but one of the subclasses, such as BBOX or Cluster or Fixed. The cluster strategy does as it says and combines point that are close together into clusters, based on a threshold, which will lead to much faster rendering times when you have many points in view. Unfortunately, the ...



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