OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2014-12-02 08:54:52

Lübeck
Member
Registered: 2009-02-17
Posts: 2,555

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

Moin!

der Roland hat als eine der ersten Anwendungen einmal die http://overpass-api.de/locate_me.html - Mini-Anwendung veröffentlicht. Auf Basis dieser habe ich diverse Karten gebastelt.

Bis vor Kurzem war dann das Problem, dass nur POI als Node ausgewertet wurden. Zwischenzeitlich können mit einer speziellen Abfrage auch für Flächen eine CENTER-Koordinate abgefragt werden.

Das ist ja auch schön und gut. Aber leider ist das mit js bei mir nicht soweit her das mir die Idee fehlt wie man diese Daten auswerten kann und in das o.g. Beispiel integrieren könnte.

Soweit ich das bisher verstanden habe wird der CENTER-Value als Objekt-Eigenschaft zurückgegeben.

Hat das einer von Euch schon einmal in dieser Form eingebunden und kann mir ein Beispiel benennen ?

Gruß Jan :-)


Android 2.2 & 4.1.1 / Webkit 3.1 / PC: Win7 64bit

Offline

#2 2014-12-02 09:05:56

TheFive
Member
Registered: 2009-05-03
Posts: 1,566
Website

Re: 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

Offline

#3 2014-12-02 13:25:50

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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

Offline

#4 2014-12-02 13:35:09

brogo
Member
From: 54,11 +-1°
Registered: 2009-06-02
Posts: 543

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

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

Offline

#5 2014-12-02 14:04:39

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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 wink

Gruss
walter

Offline

#6 2014-12-02 14:05:21

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

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

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?

Offline

#7 2014-12-02 14:17:28

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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.

Offline

#8 2014-12-02 14:35:03

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

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

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.

Last edited by Gehrke (2014-12-02 14:36:51)

Offline

#9 2014-12-02 14:43:06

Harald Hartmann
Member
From: 98667 Schönbrunn
Registered: 2014-04-02
Posts: 2,803
Website

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

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


Mein aktives Gebiet: Gemeinde Schleusegrund
Fingerprint meines Schlüssels: 71F7 3CD9 B647 9079 6B88 326E 8B8B 72AE 34F9 5AAD

Offline

#10 2014-12-02 14:51:48

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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.

Offline

#11 2014-12-02 15:45:56

couchmapper
Member
Registered: 2013-02-17
Posts: 462

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

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?

Offline

#12 2014-12-02 16:20:19

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

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

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.

Offline

#13 2014-12-02 18:17:54

TheFive
Member
Registered: 2009-05-03
Posts: 1,566
Website

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

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.

Offline

#14 2014-12-02 19:12:22

couchmapper
Member
Registered: 2013-02-17
Posts: 462

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

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.

Last edited by couchmapper (2014-12-02 19:15:08)

Offline

#15 2014-12-02 19:45:42

TheFive
Member
Registered: 2009-05-03
Posts: 1,566
Website

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

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

Offline

#16 2014-12-02 20:02:14

TobWen
Member
From: Ruhrgebiet
Registered: 2009-03-31
Posts: 1,082

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

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?


Was macht der RVR mit OpenStreetMap? https://forum.openstreetmap.org/viewtopic.php?id=63052
Aktuelle Luftbilder des RVRs (Ruhrgebiet) http://forum.openstreetmap.org/viewtopic.php?id=28511

Offline

#17 2014-12-02 22:03:12

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

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

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 smile

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

Offline

#18 2014-12-02 22:23:56

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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 wink

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

Last edited by wambacher (2014-12-02 22:26:49)

Offline

#19 2014-12-02 23:46:00

TobWen
Member
From: Ruhrgebiet
Registered: 2009-03-31
Posts: 1,082

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

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?


Was macht der RVR mit OpenStreetMap? https://forum.openstreetmap.org/viewtopic.php?id=63052
Aktuelle Luftbilder des RVRs (Ruhrgebiet) http://forum.openstreetmap.org/viewtopic.php?id=28511

Offline

#20 2014-12-03 00:43:08

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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.

Offline

#21 2014-12-03 09:28:30

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

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

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.

Offline

#22 2014-12-03 09:52:54

Gehrke
Member
From: Bremen, DE
Registered: 2013-10-19
Posts: 1,894
Website

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

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   cool

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.

Last edited by Gehrke (2014-12-03 10:06:43)

Offline

#23 2014-12-09 09:28:51

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

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

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. smile

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

Offline

#24 2014-12-09 10:26:11

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 15,496
Website

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

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

Offline

#25 2014-12-09 11:52:25

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

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

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

Offline

Board footer

Powered by FluxBB