wie prüfen ob die Geometrien stimmten mit dem osm2spatialite ?
das was ich bis jetzt sehen konnte fand ich nicht schlecht.
mit QGIS. die können spatialite.
wärst du so nett es etwas genauer zu beschreiben ? ich meine nicht wie man das mit QGis macht sondern wo rauf ich achten muss ?
Muss mal sehen wie ich an WebSpace komme dann kann ich dir ja mal die png zeigen die ich so erstellt habe…
Nö, hab ich nie benutzt, aber fällt mir jedes mal auf, dass QGIS das kann. Vermute ähnlich wie beim Zugriff auf PostGIS: Datenbank anmelden, Tabelle auswählen, evtl Filter setzten.
jag das Zeug nach pic-upload.de hoch dann kannst du es hier verlinken.
Gruss
walter
hallo du hast mich falsch verstanden. du sagtes vernünftige Geometrien raus kommen meine frage sollte sein was ist eine vernünftige Geometrien in deinen augen nicht wie ich das in QGis anzeigen kann
“vernünftige” Geometrien sind Point (node), Linestring (way) und eben die Polygone bzw Multipolygone (aus OGC-Sicht, nicht mit OSM-Multipolygonen verwechseln!).
- OSM-Nodes zu OGC-Points ist trivial.
- “offene” nicht geschlossene OSM-Ways zu OGC-Linestrings auch.
- “geschlossene” OSM-Ways müssen OGC-Polygone werden. (OSM-Special, aber immer noch trivial)
- OSM-Multipolygone, die NUR aus einfachen geschlossenen OSM-Ways bestehen, sind bei OSM sehr rar, können aber sehr einfach in OGC-Polygone und/oder OGC-Multipoygone umgesetzt werden.
- kritisch sind OSM-Multipolygone, die aus mehreren OSM-Ways pro Ring (outer/inner) bestehen. Da muß die Software ebenfalls OGC-Polygone oder OGC-Multipolygone raus machen. Und das kann nicht jede Software. osm2pgsql macht das natürlich sauber.
Letzteres ist der Knackpunkt.
Alle Klarheiten restlos beseitigt? Setzte einfach OGC == GIS und dann ist es eventuell einfacher.
Gruss
walter
Puh da gibts du mir jetzt eine Nuss zum Knacken !
Mal sehen ob ich das irgend wann wirklich verstehe.
Habe mir heute morgen noch mal ein bisschen was angesehen wie andere Software so die Daten erstellen aber im Prinzip alle die Online auf eine DB zugreifen vereinfachen vorher die Daten. auf eine fache oder komplexe Wege. Da ich auch auf diese Idee gekommen bin ist sie schon mal nicht so falsch. Ich denke genau dort liegt ein Teil der Problematik entweder wirklich vorher Rendern und dafür viel Details oder nachher dafür etwas wenigen Details.
Jetzt bekomme ich bestimmt auf die Ohren aber so mache Tags sind einfach nicht SQL Freundlich was ich meine ist:
select way, rowid, highway from layer_minor_roads_fill where tunnel = ‘no’ and highway like ‘%link’
Für die Spalte link kann man jetzt keinen Index benutzen weil das % vorne steht wenn jetzt das link vorne stehen würde könnte man link% machen und dann kann die db den index benutzen.
Und das führt dann genau zu der Frage die mich gerade rum treibt müssen die link in einen eigen layer…
Ich glaube ich werde noch mal ein paar tage ins OSM Daten modell verschwenden müssen…
Jo, postgresql kann es - irgendwie: http://stackoverflow.com/questions/1566717/postgresql-like-query-performance-variations, aber damit ist dir ja nicht geholfen.
Noch schlimmer sind variable Keys, also Konstrukte wie maxspeed:wet:30=hvg und maxspeed:wet:50=yes, wo im KEY variable numerische Werte stehen. (konstruiertes Beispiel, kenne die genaue Syntax nicht). Daher habe ich immer heftigst dagegen “gekämpft”.
Gruss
walter
schön das ich da nicht ganz alleine dastehe
ich glaube ich habe gerade die nächste grenze von sqlite gefunden:
SELECT way,pkid,[highway] FROM minor_roads_fill_links WHERE pkid IN (SELECT pkid FROM idx_layer_minor_roads_fill_way WHERE xmax>=8.307919999999999 AND xmin<=8.963480000000001 AND ymax>=49.834208 AND ymin<=50.407823)
sollte das selbe wie
select way, minor_roads_fill_links.pkid, highway from minor_roads_fill_links,idx_layer_minor_roads_fill_way WHERE minor_roads_fill_links.pkid = idx_layer_minor_roads_fill_way.pkid and xmax>=8.307919999999999 AND xmin<=8.963480000000001 AND ymax>=49.834208 AND ymin<=50.407823
bringen in meinen Augen tut es aber nicht. gefühlt steigt die spital erweiterung hier aus. mal sehen wie es weiter geht.
ist bekomme ich gleich ein knoten ins hirn
select way, osm_id, highway,tunnel
from layer_minor_roads_fill,idx_layer_minor_roads_fill_way
WHERE (layer_minor_roads_fill.rowid = pkid and xmax>=8.307919999999999 AND xmin<=8.963480000000001 AND ymax>=49.834208 AND ymin<=50.407823) and tunnel=‘no’
181855 Zeilen in 1.155 sec.
dann
CREATE INDEX Idxlayerminorroadsfill_tunnel ON layer_minor_roads_fill(tunnel,highway);
den select noch mal ergnis 0 nach 3.992 sec.
select way, osm_id, highway,tunnel
from layer_minor_roads_fill,idx_layer_minor_roads_fill_way
WHERE tunnel=‘no’ and (layer_minor_roads_fill.rowid = pkid and xmax>=8.307919999999999 AND xmin<=8.963480000000001 AND ymax>=49.834208 AND ymin<=50.407823)
181855 Zeilen in 1.169 sec
ich fürchte der Style ist einfach zu komplex um ihn online zu rendern den minor-roads-casing bekomme ich einfach nicht unter die 6 sec.
Viel Arbeit um sonst mal sehen ob ich ein anderen Ausgangsstyle finde.
Hat jemand eine Idee warum mir der Main fehlt ?
SELECT osm_id, way_area AS area,way FROM world_polygon WHERE ("natural" IN ('water', 'pond') OR waterway IN ('basin', 'canal', 'mill_pond', 'pond', 'riverbank', 'stream'))
das “orginal” ist ein png das sieht es viel besser aus aber das nur am rande
weil flüsse auch linien sind
Am SELECT habe ich erstmal mangels spatialite Wissens nichts auszusetzen (außer das canal und stream vermutlich überflüssig sind, da diese nicht als polygon vorkommen dürften; und was ist eigentlich mill_pond?), aber wenn man sich die tags der Flussbereiche anschaut, die gerendert werden, fällt auf, dass diese neben dem waterway=riverbank auch noch ein natural=water aufweisen. Es sieht also so aus, als würden bei dir nur Polygone mit natural=water gerendert. Du hast also entweder ein Problem mit der Datenbank (waterway=riverbank nicht enthalten) oder ein Problem mit dem Style.
Danke für den Tipp.
Irgendwie sind alle Styles die man so findet (ausserhalb OSM selbst) immer noch für das Projekt bzw. was man gerade zeigen will. Der Style ist der von TileMil zum zeigen der sqlite funktionalität.
Aber es fehlen halt die Flüsse weil in den Beispieldaten keine sind.
Die OSM Styles bauen halt sehr auf die Progress Funktionen und sind super Detail reich was bei Vorrendern (ich meine das die Kachel erstellt werden) nicht wirklich so tragisch ist. Ich weiß noch nicht wie ich da ein Mittelweg finde. Vielleicht gibt es ja keinen weil alle anderen fast ausschlieslich raster Karten verwenden beim online anzeigen. Zu mindestens so wie ich das gesehen habe. Oder verwenden was ganz eigenes zum Rendern.
Auf der andren Seite habe ich die Erfahrung gemacht wenn man die selects umbaut und ein bisschen die Tabelle ändern das ordentlich viel schneller ist. Gestern zum Beispiel habe ich den Strassen layer um gebaut und bin von 20 sec auf 10 sec runter.
Aber vielleicht ist das alles auch eine nummer zu groß für mich und ich sollte es aufgeben baer die Idee finde ich immer noch genial mal sehen was ich noch hin bekomme. Vor allem weil eben alles was ich verwende auch auf Linux und Andriod läuft.
Auch habe ich fest gestellt das die Zeit problem “nur” bei bestimmten Zoom stufen auf drehten also ganz Frankfurt dauert aber Zeilsheim geht dann schnell ok ich habe jetzt noch nicht probiert von Deutschland nach Zeilsheim zu Zoom wie schnell das dann ist. Gefühlt hängt es mit der schieren menge zusammen an einzeln Elementen die gerendert werden müssen. Alleine der Transport von 200.000 Objekten von Sqlite nach Mapnik braucht zeit. Im MS Debugger kann man sogar dann die Zeit für das Speicher reservieren messen. In diesem bezug finde man für Sqlite sogarn hinweise auf alternative “Speicher Manager”. Aber das ist mir dann wirklich eine Ebene zu Tief.
Habe mir jetzt mal eine Deadline von 14 Tagen gesetzt wenn ich dann deutlich weiter bin mache ich weiter wenn nicht werde ich es wohl sterben lassen und weiter nach ein Lösung suchen wie man ein Navi (Software) einbinden kann. Was teilweise aber auch nur unschön funktioniert. Zum Beispiel bei PC Nagigator bekomme ich zwar mit das er jetzt spricht aber nicht wann er Fertig ist. Die POI sind in der Freien Version auch ziemlich ein geschränkt.
Die Idee ist halt gewesen das man damit vielleicht auch wieder daten zurück führen kann nach OSM (Nutzer Einverständnis voraus gesetzt) und das man “schnell” neue Karten hat / machen kann.
Auch gefällt mir sehr das durch das XML jeder Quasi seine Karte machen kann wenn er will. Aber eine Software online stellen wo man erstmal ein Karte basteln muss macht keine Sinn es sollte ein default karte geben das man sieht es tut.
Aber ich sollte hier nicht so viel Schreiben sondern Software machen dann Tut es vielleicht auch irgend wann.
PS: Da ist ein or drin nicht ein and und so werden nicht nur Poligone von Natural = water gerendert. An dem Select ist nichts Sqllite spezifiches der läuft auf jeder sql datenbank.
Vielleicht gibt es ja einen der noch mit liest.
Ich habe jetzt auf dem OSM German Style die water lines in meine Style übernommen aber das Ergebnis sieht so völlig anders aus als Online. Könnte es sein das sich Angabe zu Linenbreite und so ändern müssen je nach Projektion / Koordinaten System (Verzeiht die Ausdrucksweise ich lerne noch).
Das sich Poligon durch meine art der erstellung viel Leicht nich so schön will ich ja glauben aber Linien sind doch Lienen oder ändert hier osm2pgsql auch was ?
weiß nicht ob noch jemand mit liest aber trotzdem
http://www.mine-robo.homepage.t-online.de/images/film1.webm
mit nur hauptstrasse und ohne Gebäude geht es
Ich weiss, dass du gewisse Probleme mit der Software hast, aber “normale” Gebäude sind doch harmlose, geschlossene Ways. Das sollte doch gehen. Die landuses gehen ja auch.
nur Mut.
Gruss
walter
ps: Ja, ich lese alles mit - oder zumindest kurz an. 
ich denke es liegt nicht an der Komplexität der Polygone sondern an der schieren Masse. Immer hin gibt es in Hessen ca. 1,1 Millionen ein gezeichnete Buildings… klar sieh man die nicht alle gleich zeitig aber genau da scheint Sqlite an die grenzen zu kommen mal sehen was ich noch so raus finde.
“normalerweise” macht man 2 Sachen:
- einen Index auf die Geometrie-Spalte: create index idx_polygon_geom using gist(geom);
und ganz am Anfang eine Abfrage … select geom
from polygon
where geom && windows_box
und bekommt so alle Objekte, deren Bbox innerhalb des auszuwertenden Bereiches liegen.
Und der ist das anzuzeigende Fenster und nicht etwa ganz Hessen.
Dabei sollte SpatiaLite den Index verwenden und somit schneller werden - wenn es das überhaupt kann.
Eine andere Sache, die ich gerne verwende:
Ich berechne pro Polygon einen “Mittelpunkt” und benutze den für Spatiale Abfragen. Bläht die Rohdaten (Tabelle Polygon) natürlich auf, braucht dafür aber nur einmal berechnet zu werden. Dafür nehme ich st_pointonsurface(geom) anstelle von st_centroid(geom), weil dieser Punkt immer innerhalb der Fläche (hier deine Buildings) liegt. Aber sowas wie st_centroid sollte SL auch haben und ist besser/schneller als garnix.
So, genug Futter für die Ostertage
Gruss
walter