Begrenzungsrahmen mit postGIS auswählen?

36

Ich möchte mit postGIS eine Abfrage erstellen, um alle Wege und ihre Knoten innerhalb eines Begrenzungsrahmens auszuwählen. Der Begrenzungsrahmen muss alle Details enthalten, die der Osmose-Befehl "--bounding-box" abruft.

Gibt es eine Möglichkeit, das zu tun?

— uriel
quelle

36

Für die Osmose-Dokumentation sehe ich die Befehlsoption :

--bounding-box top=49.5138 left=10.9351 bottom=49.3866 right=11.201

Für PostGIS können Sie ST_MakeEnvelope (links, unten, rechts, oben, srid) verwenden , um einen Begrenzungsrahmen zu erstellen, und dann den &&Begrenzungsrahmenoperator, um zu ermitteln, wo sich die Begrenzungsrahmen schneiden:

SELECT *
FROM mytable
WHERE mytable.geom && ST_MakeEnvelope(10.9351, 49.3866, 11.201, 49.5138, 4326);

Die SRID 4326 ist für WGS84 Lat / Long und nur für PostGIS 1.5 erforderlich. es kann für spätere Versionen weggelassen werden.

— Mike T
quelle

Vielen Dank. Die Funktion ST_MakeEnvelope benötigt einen weiteren Parameter, srid. Ich weiß nicht, was ich dort hinstellen soll.

— Uriel

1

Anscheinend verwenden Sie PostGIS 1.5, für das dieser Parameter erforderlich ist. Ich denke, dass SRID ignoriert wird, so dass jeder Wert die gleichen Ergebnisse liefern kann. Wenn Sie Lat / Long-Daten haben, verwenden Sie im Allgemeinen eine SRID von 4326.

— Mike T

1

In den meisten Tools können Sie heutzutage die SRID für OSM-Daten beim Laden auswählen. Die Standard-OSM-SRID ist 3857 (sphärischer Mercator). Die Standard-SRID für die meisten Lat / Lon-Daten ist SRID 4326 (Lat / Lon AKA WGS84). Wenn Sie die Daten mit SRID 3857 laden, müssen Sie beispielsweise eine Konvertierung von LAT / LON WGS84 in 3857 durchführen: ST_Transform (ST_MakeEnvelope (LON1, LAT1, LON2, LAT2, 4326), 3857) Einige Tools (wie imposm3) Derzeit unterstützt nur SRID 3857

— Justin Swanhart

Beachten Sie, dass der Operator && keine SRIDs für Sie transformiert. Stellen Sie sicher, dass sich die von Ihnen erstellte Hüllkurve in derselben SRID befindet wie die Testgeometrie, oder transformieren Sie sie selbst. trac.osgeo.org/postgis/ticket/2320

— Nelson

1

Der Operator && ist rechnerisch langsamer als ST_Intersects

— caiohamamura

8

Ich denke, es wird ungefähr so aussehen: Der Begrenzungsrahmen in PostGIS wird von erstellt

ST_GeomFromText('POLYGON((ulx uly, urx ury, llx llr, lrx lry, ulx uly))', <srid>)

Die Abfrage verwendet ST_Intersection mit einer Unterabfrage.

SELECT bbox_nodes.id, bbox_nodes.tag, nodes_geom 
FROM (SELECT nodes.id, nodes.tag, 
   ST_Intersection(nodes.the_geom, 
      ST_GeomFromText('POLYGON((ulx uly, urx ury, llx llr, lrx lry, ulx uly))', <srid> )).geom AS nodes_geom
   FROM nodes 
   WHERE ST_Intersects(nodes.the_geom, 
      ST_GeomFromText('POLYGON((ulx uly, urx ury, llx llr, lrx lry, ulx uly))', <srid> )) AS bbox_nodes
WHERE ST_Dimension(bbox_nodes.nodes_geom)=0;

Ich habe dies mehr oder weniger von den PostGIS-Hilfeseiten übernommen.
Eine zweite Abfrage in der Wegetabelle, die ähnlich wie oben entworfen wurde (aber mit ST_Dimension () = 1), sollte die Wege abrufen.

HTH, Micha

— Micha
quelle

Hallo danke! Was zum Teufel? was muss ich in <srid> einfügen? und ".geom" (Zeile 4) es scheint ungültig zu sein, sollte es da sein?

— Uriel

Entschuldigung, ich habe deinen Kommentar von letzter Woche verpasst. Das srid ist der Code des Koordinatenreferenzsystems. dh 2039 für Israel. Der .geom-Zusatz extrahiert den Geometrieteil einer "GeometryCollection". Vielleicht haben Sie recht, dass er hier nicht erforderlich ist.

— Micha

4

es gibt hier ein Thema auf Ihre Frage ähnlich , die hier ...

ST_Intersection - (T) Gibt eine Geometrie zurück, die den gemeinsam genutzten Teil von geomA und geomB darstellt. Die Geografieimplementierung führt eine Transformation in Geometrie durch, um die Schnittmenge zu erstellen, und transformiert dann zurück in WGS84.

1.you kann auch einige Informationen bekommen hier über Geometrie Konstruieren von Funktionen.

SELECT ST_AsText(ST_Intersection(
  ST_Buffer('POINT(0 0)', 2),
  ST_Buffer('POINT(3 0)', 2)
));

Überschneidung

2.Another Informationen hier über durchteuft Überschneidung: PostGIS - ST_Intersects, ST_Intersection ...

SELECT b.the_geom As bgeom, p.the_geom As pgeom, 
        ST_Intersection(b.the_geom, p.the_geom) As intersect_bp
    FROM buildings b INNER JOIN parcels p ON ST_Intersection(b,p)
    WHERE ST_Overlaps(b.the_geom, p.the_geom)
    LIMIT 1;

Überschneidung

ich hoffe es hilft dir ...

— Aragon
quelle

0

Dies ist ein Kommentar zu @ Michas Code.

Die Koordinatenpaare für POLYGONsollten im Uhrzeigersinn (oder gegen den Uhrzeigersinn) angeordnet sein: links oben, rechts oben, rechts unten, links unten, wieder links oben.

Im Uhrzeigersinn sollte der Funktionsaufruf also sein:

ST_GeomFromText('POLYGON((ulx uly, urx ury, lrx lry, llx llr, ulx uly))', <srid>)

Oder gegen den Uhrzeigersinn:

ST_GeomFromText('POLYGON((ulx uly, llx llr, lrx lry, urx ury, ulx uly))', <srid>)

— Daishi
quelle