Overpass-Api - Anpassungen für Center bei Flächen

Vermute diese Stelle

␣␣␣␣␣function␣showCustomLayer(query)
{
hideCustomLayers();
var␣layer␣=␣make_auto_zoom_layer("http://overpass-api.de/api/interpreter?data="␣+␣query␣+␣"out+skel;",␣"blue",␣11);
map.addLayers([layer]);
customLayers.push(layer);
layer.display(true);
}

ersetze out+skel durch out+center.

Christoph

Lübeck wrote:

Zwischenzeitlich können mit einer speziellen Abfrage auch für Flächen eine CENTER-Koordinate abgefragt werden.

hi, ich bin bei der Overpass nicht so drin, aber könnte jemand den Autor (Roland?) bitten, neben Center auch PointOnSurface zu ermöglichen?

Er schafft eh mit PostGis und da ist das ein Klacks.

Grund: bei bestimmten Flächentypen (z.B. das "Große C"), liegt das Zentrum (Schwerpunkt) außerhalb der Fläche, bei PointOnSurface ist er aber garantiert immer drin. Und liegt auch normalerweise bei "harmlosen" Flächen nah beim Zentrum.

Gruss
walter

wambacher wrote:

Er schafft eh mit PostGis und da ist das ein Klacks.

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Christian

brogo wrote:

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Jo? nun, ich dachte da würde PostGis laufen mit einem eigenen Schema - also gleiche Software mit total anderer Datenstruktur.
Aber wenn die sogar die Spatialen Funktionen selber machen sollten, gibt es echt was - mMn unnötiges - zu tun.

dann halt ohne Blub Klacks 😉

Gruss
walter

brogo wrote:

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Das DBMS mit seinen Funktionen und Erweiterungen (PostGIS) auch?? Warum?

Gehrke wrote:

brogo wrote:

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Das DBMS mit seinen Funktionen und Erweiterungen (PostGIS) auch?? Warum?

naja, die Performance ist schon extrem gut. Wenn man auf eine DB verzichtet und alles hardcoded, bringt das natürlich Leistung. Nur der Preis der fehlenden Flexibilität ist schon ziemlich hoch.

wambacher wrote:

Gehrke wrote:

brogo wrote:

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Das DBMS mit seinen Funktionen und Erweiterungen (PostGIS) auch?? Warum?

naja, die Performance ist schon extrem gut. Wenn man auf eine DB verzichtet und alles hardcoded, bringt das natürlich Leistung. Nur der Preis der fehlenden Flexibilität ist schon ziemlich hoch.

DBMS sind im Prinzip meist auch schon sehr gut. Man muss halt ein geeignetes Schema wählen und natürlich passende Indexe erzeugen.
Meine Beobachtung bei Auswertungen mit PostgreSQL ist, dass die CPU wenig tut und I/O die ganze Zeit frisst. Wenn ich die Daten (wenigstens die Indexe) weitgehend im Speicher halten könnte, wäre das ein Traum.

Welche Datenverwaltung und -haltung nutzt denn Overpass?

Sooo toll kann die auch nicht sein, wenn meine Adressauswertung anscheinend schneller läuft - allerdings nicht mit einer OSM-Live-Datenbank.

zurück zum eigentlichen Thema

@Jan (Lübeck): wenn du das out+center nutzt dann darauf achten, dass du, wenn du überhaupt lat und lon manuell auswertest, dass lat und lon dann bei way und rel in einem subtag "center" steht:

{
"type":␣"node",
"id":␣2524879116,
"lat":␣50.4801376,
"lon":␣10.6406411,
"tags":␣{
"amenity":␣"recycling"
}
},
{
"type":␣"way",
"id":␣96954330,
"center":␣{
"lat":␣50.5092641,
"lon":␣10.7424673
},
"nodes":␣[
1123509670,
3057384307,
1123509672,
1123509673,
1123509670
],
"tags":␣{
"addr:city":␣"Schleusingen",
"addr:country":␣"DE",
}
}

siehe auf http://forum.openstreetmap.org/viewtopi … 16#p464516

Gehrke wrote:

Wenn ich die Daten (wenigstens die Indexe) weitgehend im Speicher halten könnte, wäre das ein Traum.

Ich habe viele Indices per Tablespace auf SSD gelegt. Das kostet relativ wenig und bringt schon sehr viel. Mag aber sein, dass du alles auf SSD hast, dann bringt das natürlich nix.

Gehrke wrote:

Sooo toll kann die auch nicht sein, wenn meine Adressauswertung anscheinend schneller läuft - allerdings nicht mit einer OSM-Live-Datenbank.

Das lässt sich so nicht wirklich beantworten. Wie sieht deine DB/Schema aus? Was ist da alles an Daten drin (kompletter Planet mit 2 Jahren History,...?). Was hast du an Overpass Query probiert? Wie sieht deine Query aus? Wie sieht der Laufzeitunterschied aus?

couchmapper wrote:

Gehrke wrote:

Sooo toll kann die auch nicht sein, wenn meine Adressauswertung anscheinend schneller läuft - allerdings nicht mit einer OSM-Live-Datenbank.

Das lässt sich so nicht wirklich beantworten. Wie sieht deine DB/Schema aus? Was ist da alles an Daten drin (kompletter Planet mit 2 Jahren History,...?). Was hast du an Overpass Query probiert? Wie sieht deine Query aus? Wie sieht der Laufzeitunterschied aus?

Ich habe probiert, die Adressen eines ganzen Bundeslandes (BaWü) zu zählen und als CSV pro Gemeinde auszugeben. Das ging aber nicht (Ein anderes Beispiel für nur einen Kreis ging recht flott).
Nein, ich habe keine History und nutze ein eigenes Schema in PostgreSQL. Die erwähnte Auswertung dauert auf meinem Rechner knapp 5 Sekunden. Ich meine ja auch nicht, dass man das wirklich vergleichen kann.

Nicht falsch verstehen. Overpass ist eine tolle Sache. Ich will das nicht herabsetzen.

Interessehalber frage ich mich nur, was für eine Datenhaltung Overpass nutzt.

Gehrke wrote:

brogo wrote:

Die Datenbank für die Overpass-API ist komplett selbst und neu entwickelt.

Das DBMS mit seinen Funktionen und Erweiterungen (PostGIS) auch?? Warum?

Roland
Verzichtet komplett auf Transaktionen. Das Ding ist read only ausgelegt, und wenn es auf die Nase fällt muss er die DB komplett neu aufbauen.
D.h. Mehr Performanz, weniger transaktionale Absicherung.

Ich würde den FOSSGIS 2012 Tagungsband ab Seite 120 empfehlen. Da steht ziemlich viel technisches Detail zu Overpass API drin: http://mapmedia.de/downloads/viewcatego … agungsband

Gehrke wrote:

Das ging aber nicht

Mit einem Permalink könnte man ggfs. das mal checken.

TheFive wrote:

Verzichtet komplett auf Transaktionen. Das Ding ist read only ausgelegt, und wenn es auf die Nase fällt muss er die DB komplett neu aufbauen.
D.h. Mehr Performanz, weniger transaktionale Absicherung.

Ne, das kann nicht sein, da laufen ja kontinuierlich Updates von der Haupt-OSM DB rein.

couchmapper wrote:

Ne, das kann nicht sein, da laufen ja kontinuierlich Updates von der Haupt-OSM DB rein.

Ok "komplett" war evtl. ein bisschen extremistisch. Aber Aussage von Roland in Bonn war genau, das seine DB durch Verzicht auf den ganzen Sicherheitskram deutlich schlanker im Source ist und deutlich schneller. (Die geringen lines of Code - die ich nicht gemerkt habe - fande ich schon interessant).

Christoph

wambacher wrote:

Ich habe viele Indices per Tablespace auf SSD gelegt. Das kostet relativ wenig und bringt schon sehr viel. Mag aber sein, dass du alles auf SSD hast, dann bringt das natürlich nix.

Wieviel MB belegen die Indizes bei dir?

Nahmd,

Gehrke wrote:

Meine Beobachtung bei Auswertungen mit PostgreSQL ist, dass die CPU wenig tut und I/O die ganze Zeit frisst. Wenn ich die Daten (wenigstens die Indexe) weitgehend im Speicher halten könnte, wäre das ein Traum.

Nach meiner Erfahrung bremsen die Seeks aus.

Mit einem passenden Index findest Du blitzschnell heraus, wo auf der Disk Deine 10.000 Treffer liegen. Bei so 300 Seeks/s braucht das Ansteuern der Treffer alleine 30 Sekunden. Der eigentliche Datentransfer spielt praktisch keine Rolle.

Ich halte deshalb alle Daten gleich drei mal: einmal nach Koordinaten sortiert, einmal zuerst nach Key und dann nach Koordinaten, und einmal zuerst nach Value, dann nach Key und dann nach Koordinaten. Einfache Anfragen mit ein paar zigtausend Treffern werden damit instantan beantwortet, die knapp 500k Geschichtskarten-POIs werden in etwas über zwei Minuten aus ~200 Einzelanfragen zusammengesetzt. Je Anfrage (vom Index abgesehen) nur 1 Seek, und 200× Seek+(im Schnitt) 0.4Mb lesen ist schneller als 500.000× Seek+200Bytes lesen. Leider ist nichts umsonst: Die Monsterdateien zu sortieren ist so aufwendig, dass ich nur einmal am Tag aktualisieren kann. Für QS-Aktionen völlig ungeeignet. Ich definiere diesen Bug aber zu einem Feature: die DB hat immer einen vollkommen konsistenten Bearbeitungsstand 🙂

In Postgres kann man das nachbilden, indem man Untertabellen zu einer Tabelle anlegt und das Konstrukt mit Constraints/Rules so ausstattet, dass Objekte in die gleiche Untertabelle gepackt werden, die bei häufigen Anfragen auch zusammen im Ergebnis erscheinen. Z.B. die Welt mit 200 Rechtecken überdecken, wenn man oft regional sucht. Leider vertragen sich die Untertabellen nicht mit Foreign-Keys, sie können nur auf Einzeltabellen zeigen, aber nicht auf die Hierarchie als ganzes. Das soll geändert werden; das Feature ist angekündigt, war aber bei meinem letzten Blick in die Doku noch nicht implementiert.

Gruß Wolf

TobWen wrote:

wambacher wrote:

Ich habe viele Indices per Tablespace auf SSD gelegt. Das kostet relativ wenig und bringt schon sehr viel. Mag aber sein, dass du alles auf SSD hast, dann bringt das natürlich nix.

Wieviel MB belegen die Indizes bei dir?

zu viel 😉

hier mal die wichtigsten. Hab natürlich noch mehr, da man die ja nach Bedarf zusätzlich anlegen kann.

public␣|␣planet_osm_line_index␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣23␣GB␣␣␣␣␣␣|
public␣|␣planet_osm_line_pkey␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣2904␣MB␣␣␣␣|
public␣|␣planet_osm_line_tags_index␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣23␣GB␣␣␣␣␣␣|
public␣|␣planet_osm_nodes_pkey␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_nodes␣␣␣|␣8192␣bytes␣|
public␣|␣planet_osm_point_index␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣3515␣MB␣␣␣␣|
public␣|␣planet_osm_point_pkey␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣2003␣MB␣␣␣␣|
public␣|␣planet_osm_point_tags_index␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣10␣GB␣␣␣␣␣␣|
public␣|␣planet_osm_polygon_index␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣14␣GB␣␣␣␣␣␣|
public␣|␣planet_osm_polygon_pkey␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣3565␣MB␣␣␣␣|
public␣|␣planet_osm_polygon_tags_index␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣24␣GB␣␣␣␣␣␣|
public␣|␣planet_osm_rels_idx␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_rels␣␣␣␣|␣14␣MB␣␣␣␣␣␣|
public␣|␣planet_osm_rels_parts␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_rels␣␣␣␣|␣3887␣MB␣␣␣␣|
public␣|␣planet_osm_rels_pkey␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_rels␣␣␣␣|␣150␣MB␣␣␣␣␣|
public␣|␣planet_osm_roads_index␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_roads␣␣␣|␣3641␣MB␣␣␣␣|
public␣|␣planet_osm_roads_pkey␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_roads␣␣␣|␣386␣MB␣␣␣␣␣|
public␣|␣planet_osm_roads_tags_index␣␣␣|␣index␣|␣postgres␣|␣planet_osm_roads␣␣␣|␣3989␣MB␣␣␣␣|
public␣|␣planet_osm_ways_idx␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_ways␣␣␣␣|␣2641␣MB␣␣␣␣|
public␣|␣planet_osm_ways_nodes␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_ways␣␣␣␣|␣136␣GB␣␣␣␣␣|
public␣|␣planet_osm_ways_pkey␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_ways␣␣␣␣|␣13␣GB␣␣␣␣␣␣|

und␣selbst␣erzeugte:
public␣|␣idx_boundaries_type␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣boundaries␣␣␣␣␣␣␣␣␣|␣6160␣kB␣␣␣␣|
public␣|␣idx_boundaries_value␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣boundaries␣␣␣␣␣␣␣␣␣|␣9432␣kB␣␣␣␣|
public␣|␣idx_changesets_name␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣changesets␣␣␣␣␣␣␣␣␣|␣353␣MB␣␣␣␣␣|
public␣|␣idx_changesets_uid␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣changesets␣␣␣␣␣␣␣␣␣|␣280␣MB␣␣␣␣␣|
public␣|␣idx_countries2_id␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣countries2␣␣␣␣␣␣␣␣␣|␣261␣MB␣␣␣␣␣|
public␣|␣idx_countries2_level␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣countries2␣␣␣␣␣␣␣␣␣|␣256␣MB␣␣␣␣␣|
public␣|␣idx_countries2_ts␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣countries2␣␣␣␣␣␣␣␣␣|␣255␣MB␣␣␣␣␣|
public␣|␣idx_destatis_ags␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣destatis␣␣␣␣␣␣␣␣␣␣␣|␣360␣kB␣␣␣␣␣|
public␣|␣idx_exifs_geom␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣exifs␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣304␣kB␣␣␣␣␣|
public␣|␣idx_line_highway␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣6683␣MB␣␣␣␣|
public␣|␣idx_line_natural␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣3803␣MB␣␣␣␣|
public␣|␣idx_line_postal_code␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣26␣MB␣␣␣␣␣␣|
public␣|␣idx_line_postcode␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣11␣MB␣␣␣␣␣␣|
public␣|␣idx_line_ref␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣6818␣MB␣␣␣␣|
public␣|␣idx_line_route␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_line␣␣␣␣|␣7598␣MB␣␣␣␣|
public␣|␣idx_point_hkts␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣368␣kB␣␣␣␣␣|
public␣|␣idx_point_place␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣120␣MB␣␣␣␣␣|
public␣|␣idx_point_postcode␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣723␣MB␣␣␣␣␣|
public␣|␣idx_point_traffic_sign␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_point␣␣␣|␣8608␣kB␣␣␣␣|
public␣|␣idx_polygon_admin_level␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣3519␣MB␣␣␣␣|
public␣|␣idx_polygon_boundary␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣3528␣MB␣␣␣␣|
public␣|␣idx_polygon_pcl␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣5478␣MB␣␣␣␣|
public␣|␣idx_polygon_pos␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣11␣GB␣␣␣␣␣␣|
public␣|␣idx_polygon_postal_code␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣1952␣kB␣␣␣␣|
public␣|␣idx_polygon_postcode␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_polygon␣|␣374␣MB␣␣␣␣␣|
public␣|␣idx_roads_ref␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣index␣|␣postgres␣|␣planet_osm_roads␣␣␣|␣370␣MB␣␣␣␣␣|

eine 250 GB SSD sollte erst mal ausreichen, aber ne 500-er ist ja auch nicht mehr so teuer. Real hab ich eine 120-er und eine 250-er, aber da sind noch einige andere Daten drauf. z.B. das Flat-File für osm2pgsql mit ca 25 GB.

Gruss
walter

wambacher wrote:

hier mal die wichtigsten. Hab natürlich noch mehr, da man die ja nach Bedarf zusätzlich anlegen kann.

Danke für die Info. Lädst du normale Tags oder gleich hstore mit?

TobWen wrote:

Danke für die Info. Lädst du normale Tags oder gleich hstore mit?

Mit hstore:

export␣OSM2PGSQL=/opt/install/osm/osm2pgsql-wno/osm2pgsql

bzip2␣-d␣-c␣-k␣$2␣␣|␣\
$OSM2PGSQL␣--verbose␣-c␣-s␣--style␣wno.style␣-d␣$1␣-l␣-U␣postgres␣\
--hstore-all␣--hstore-add-index␣\
--flat-nodes␣nodes.flat␣\
--tablespace-index␣tablespace1␣\
--tablespace-main-data␣tablespace2␣--tablespace-main-index␣tablespace1␣\
--tablespace-slim-data␣tablespace2␣--tablespace-slim-index␣tablespace1␣\
--extra-attributes␣\
-C␣1000␣\
--number-processes␣4␣\
--keep-coastlines␣\
-G␣\
-

wno.style enthält nur noch 3-4 neue felder, nix besonderes.

Netzwolf wrote:

Mit einem passenden Index findest Du blitzschnell heraus, wo auf der Disk Deine 10.000 Treffer liegen. Bei so 300 Seeks/s braucht das Ansteuern der Treffer alleine 30 Sekunden. Der eigentliche Datentransfer spielt praktisch keine Rolle.

Stimmt. Da macht es dann der Index alleine nicht. Deshalb habe ich für in Abfragen wiederkehrende Datensätze teils gespiegelte Subset-Tabellen. Nicht sonderlich schön, weil redundant, kann aber viel helfen.

couchmapper wrote:

Gehrke wrote:

Das ging aber nicht

Mit einem Permalink könnte man ggfs. das mal checken.

couchmapper wrote:

Mal was sehr experimentelles für Zwischendurch: http://overpass-turbo.eu/s/6kN 😎

Genau dieses nur mit kürzerem Pattern, z.B. "de:amtlicher_gemeindeschluessel"~"0811.*" (Das ging eben sogar in 304 Sekunden)

Ein Problem ist wohl, dass dann auch alle betroffenen Kreise nochmals als Ganzes gezählt werden.

Antwort bitte hier: http://forum.openstreetmap.org/viewtopi … 08#p468508

PS: Sorry, ich wollte den Thread nicht so Off-Topic ziehen.

Moins,

Gehrke wrote:

Stimmt. Da macht es dann der Index alleine nicht. Deshalb habe ich für in Abfragen wiederkehrende Datensätze teils gespiegelte Subset-Tabellen. Nicht sonderlich schön, weil redundant, kann aber viel helfen.

Willkommen im Club. 🙂

Damit bekomme ich z.B. die Postleitzahlen-Irrläufer für DE (als angereicherte POI-Liste und als Übersicht nach Region in um 2 Minuten, dito die Hausnummern ohne Straße (als angereicherte POIs und Übersicht).

Gruß Wolf

Netzwolf wrote:

Damit bekomme ich z.B. die Postleitzahlen-Irrläufer für DE (als angereicherte POI-Liste und als Übersicht nach Region in um 2 Minuten, dito die Hausnummern ohne Straße (als angereicherte POIs und Übersicht).

Prima, dann stell die Online und ich hab ein Problem wenigen.

Gruss
walter

Moins,

wambacher wrote:

Netzwolf wrote:

Damit bekomme ich z.B. die Postleitzahlen-Irrläufer für DE (als angereicherte POI-Liste und als Übersicht nach Region in um 2 Minuten, dito die Hausnummern ohne Straße (als angereicherte POIs und Übersicht).

Prima, dann stell die Online und ich hab ein Problem wenigen.

Die stehen als CSV online unter obigen URLs.

Die Magie besteht darin, die POIs in allen Areas gleichzeitig zu suchen, die Geschwindigkeit wird also mit Speicherverbrauch (alle Grenzen gleichzeitig geladen) bezahlt. Dies in den OP einzubauen sollte möglich sein, und der Query-Optimizer vom PostGis sollte es auch hinbekommen.

Ich hätte noch die Admin-Boundaries der Welt im Angebot (als angereicherte POIs und als Übersicht), die brauchen etwa 20 Sekunden. Sucht aber nur den *Mittelpunkt* der jeweiligen Region im Land, kann also bei ungehörigen Grenzverläufen Fehler enthalten. Zu einer Version für Area in Area hab ich im Moment nicht die Zeit.

Alles jedoch nur einmal täglich aktualisiert, nachmittags mit Datenstand Mitternacht, damit für QS völlig ungeeignet. Aber vielleicht brauchbar für Fortschrittsstatistiken, weil der Datenstand genau definiert ist.

Gruß Wolf

wambacher wrote:

Mit hstore

Meines sieht recht ähnlich aus. Ich habe die Tablespaces aber "RAID" und "SSD" genannt, weil ich sonst immer durcheinander komme.

Achja, der RAID-0 Tablespace läuft seit 4 Jahren ohne Probleme 24/7 😄

TobWen wrote:

Achja, der RAID-0 Tablespace läuft seit 4 Jahren ohne Probleme 24/7 😄

Mein Raid-0 ist zur Zeit "degraded", läuft also nur mit 2 anstelle von 3 Drives. Deswegen ist die Performance auch grottenschlecht.
Fühl mich garnicht wohl dabei, aber eine Dasi von 670 GB hab ich noch nicht hinbekommen und vorher will ich da nicht rumschrauben.

Gruss
walter

wambacher wrote:

Mein Raid-0 ist zur Zeit "degraded"

Null degraded? Meinst du 10, 50 oder 5?

TobWen wrote:

wambacher wrote:

Mein Raid-0 ist zur Zeit "degraded"

Null degraded? Meinst du 10, 50 oder 5?

oops: Raid-5 natürlich.

Bin gerade dabei, die DB mit Slony auf einem anderen Server zu spiegeln, damit ich den aktuellen Server neu aufsetzen kann und der Laden dennoch weiterläuft. Und wenn das nicht funzt, mach ich halt ne Woche dicht.

Gruss
walter