Verfasste Forenbeiträge

Ansicht von 14 Beiträgen - 1 bis 14 (von insgesamt 14)
  • Autor
    Beiträge
  • als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34501

    cebewee
    Teilnehmer

    OK, ich habs….: rowid

    That’s also the reason why deleting entries might break the database: For some reason, the locus guys decided to use the ROWID as the primary key, but this is not guaranteed to remain stable.

    If you have time, you can experiment with adding an integer primary key to the Points table (which will then be also the ROWID). However, I don’t know whether Locus will be able to handle that.

    1 Teilnehmer(n) gefällt dieser Beitrag
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34499

    cebewee
    Teilnehmer

    As I use a Python Script from this thread its on the Autor @cebewee (if he has resources for) to modify the script so that the appropriate fileds in the LocusPoi-Base are filled.

    Hi Christian, the script was written by Juergen; I just prepared a few patches (and am willing to produce further patches, if Juergen is willing to merge them). On this topic @juergenl — do you have any concerns about my patches for performance improvements? For me, it reduced runtime by a factor of 3, so I’d like to see them merged :)

    Best regards, Lars

    • Diese Antwort wurde geändert vor 5 Tagen, 19 Stunden von  cebewee.
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34188

    cebewee
    Teilnehmer

    This would be an option if the storage can be afforded. Another option would be using _oam.osm.map for all applications.

    Unfortunately, locus-actions seem to not support renaming files.

    2 Benutzer dankten dem Autor für diesen Beitrag.
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34173

    cebewee
    Teilnehmer

    Ich bin sehr zurückhaltend darin, beliebige Sachen in den Systemverzeichnissen abzulegen, deswegen empfehle ich das ungern.

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34165

    cebewee
    Teilnehmer

    Wenn das nicht klappen sollte, werde ich Unterstützung für os.add_dll_directory() in das Skript integrieren (scheint ab Python 3.8 notwendig zu sein).

    So nervig solche Aktionen sind, man lernt doch immer was dazu, <https://bugs.python.org/issue36085&gt; war für mich sehr erhellend.

    • Diese Antwort wurde geändert vor 3 Wochen, 3 Tagen von  cebewee.
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34161

    cebewee
    Teilnehmer

    Du brauchst die Python-spatialite-Bibliothek. Wenn du pip hast, solltest du die mit
    pip3 install spatialite
    installieren können. Zusätzlich brauchst du noch die notwendigen DLLs. Probiere mal folgendes:

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34157

    cebewee
    Teilnehmer

    Hi Christian,

    ich hatte gehofft, dass du Linux oder OS X nutzt ;) Unter Windows ist das mit den Shared Libraries leider ein Graus. Ich habe es bei mir zum Laufen gekriegt, aber noch keinen sauberen Weg, um das auch weiterzugeben. Immerhin braucht es für deinen Anwendungszweck nur spatialite, nicht aber osmium, daher ein Problem weniger …

    Ich schaue, dass ich was einfaches finde.

    Viele Grüße, Lars

    1 Teilnehmer(n) gefällt dieser Beitrag
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34107

    cebewee
    Teilnehmer

    Soweit ich weiss, muss die ‘xxx.osm.map’ eine original (dummy) Locus-Map sein. Die eingentliche Karte (OAM), kann jeden willkuerlichen Namen haben.

    Nein, habe ich eben mit einer OoenAndroMap ausprobiert (Locus 3.44.1), funktioniert.

    Derzeit wenden die Karten alle auf _ML, das sollte reichen, dass die sich nicht überlappen.

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34101

    cebewee
    Teilnehmer

    Derzeit braucht der poi_converter ein 3er Python (3.7 habe ich getestet, geht vermutlich auch etwas älteres). Python 2 wird nicht unterstützt, da Python 2 auch seit Anfang des Jahres nicht mehr gewartet wird, würde ich da auch nur ungern Zeit reinstecken, es zu portieren.

    Bei den allermeisten Distros kannst du problemlos parallel zu Python 2 die Pakete für Python 3 installieren — wäre das eine Option?

    Bezüglich der Auslieferung von Karten mit POIs ist mir auch noch eine Komplikation aufgefallen: Damit die POI-Datenbank von Locus erkannt wird, muss

    • die POI-DB einen Namen haben, der auf osm.db endet
    • und daneben eine Karte liegen, die den gleichen Namen hat und auf osm.map endet

    D.h., entweder müsstest du die Karten umbenennen (nach .osm.map statt bisher .map) oder mit den POIs eine zusätzliche leere Karte ausliefern (die dann vmtl. die Nutzer irritiert).

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34097

    cebewee
    Teilnehmer

    Also, wenn es nun nicht reicht mit den vorhandenen Tools im Batchmode die bereits erzeugte POI-Datei ins Locus Format umzuwandeln (haben die Tools einen Batchmode??) wird es schwierig.

    Derzeit lässt sich das der poi_converter in der Form
    python poi_converter.py <input.poi> <output.db> -if poi -om create aufrufen, d.h. jeweils für eine Datei. Welches Aufrufformat wäre für dich am praktischsten?

    Locus Maps hat das Feature, zu einem POI den Link auf Openstreetmap bereitzustellen. Da die OSM-Id in den POI-Dateien fehlt, wird dann zwangsweise ein inkorrekter Link erzeugt. Fände ich jetzt allerdings ein verschmerzbares Problem.

    Denn dann müsste jemand einen Locus-Poi-Writer schreiben der aus den fertig vorbereiteten OSM-Daten und dem POI-Mapping.xml eine Locus POI Datei erstellt.

    D.h. ein passendes Plugin für osmosis?

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #34083

    cebewee
    Teilnehmer

    Christian, wärest grundsätzlich du bereit, das Erzeugen der Locus-DB in deinen Workflow mit aufzunehmen? Wenn ja, was muss das Tooling dafür bereitstellen?

    Hintergrund meiner Frage ist der folgende. Wenn ich das richtig sehe, enthalten die POI-Dateien nicht alle notwendigen Informationen, um eine saubere Datenbank für Locus zu erzeugen: Es fehlen die OSM-Node-Id und der Typ (Punkt bzw. Weg). D.h., um hier alles abzubilden müsste man wohl vorher in der Kette einsetzen.

    Viele Grüße, Lars

    2 Benutzer dankten dem Autor für diesen Beitrag.
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #28650

    cebewee
    Teilnehmer

    The poi positions are stored in the poi_index table; the poi_index_node, poi_index_rowid, poi_index_parent tables are just an artifact of the poi_index table using an R*Tree index. See https://www.sqlite.org/draft/rtree.html.

    That means, all the information you need can be obtained by quering the poi_index table. The tables poi_index_node and so on can be safely ignored.

    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #24612

    cebewee
    Teilnehmer

    I have been able to successfully create an empty database from scratch. I wrote down the description on https://gitlab.com/noschinl/locus-poi-db. The input subdirectory contains a Jupyter notebook creating such a file. I don’t know when I’ll find time to continue, so I’ll just put this out here.

    Entries can be added just like Lmu described.

    3 Benutzer dankten dem Autor für diesen Beitrag.
    als Antwort auf: POI: Nutzbarkeit der Dateien mit Locus #23782

    cebewee
    Teilnehmer

    Ich hoffe ja immer noch, dass jemand die Locus-POI-DB-Mechanik komplett reverse engineered, so dass man die Locus-POI-DBs direkt selbst erstellen kann … Es ist auf jeden Fall nicht einfach. Gaouargas und ich haben uns bisher die Zähne daran ausgebissen …

    Ich habe mir heute das Format der Datenbank mal kurz angeschaut. Auf den ersten Blick sieht das Format nicht zu schlimm aus. Wenn man sich die Blobs in den „geom“-Feldern anschaut, findet man raus, dass die Werte alle mit dem Wert 0001E6100000 (in Hex-Darstellung) anfangen. Wenn man mal danach googlet, findet man relativ schnell heraus, dass das vermutlich irgendwas mit spatialite zu tun hat (eine Bibliothek für spatial data in SQLite).

    Öffnet man jetzt die Datei in spatialite gui, so gibt es da nur eine begrenzte Zahl an Nutzer-Tabellen: Cities, Cities_Names, FoldersRoot, FoldersSub, MetaData, Points, Points_Key_Value, Points_Root_Sub, Postcodes, Regions, Regions_Names, Street_In_Cities, Streets, TagKeys, TagValues sowie einen View View_Cities_Def_Names. Das Datenmodell dieser Tabellen sieht auf den ersten Blick erstmal recht einfach zu verstehen aus — in der GUI sieht man insbesondere, das die „geom“-Spalte nicht einfach nur ein Blob ist, sondern z.B. ein MULTIPOLYGON (z.B. in Cities, also die Umrisse der Stadt) oder ein POINT (z.B. in Points).

    Man kann die Datei auch in QGIS laden (als spatialite-Datei) und dann z.B. die Städte als Layer einblenden

    Der große Rest der Tabellen erscheinen mir interne Tabellen von bzw. für spatialite zu sein.

    Soweit als Abendanalyse der POI-Daten. Vielleicht hilft das schon mal jemandem weiter, aber zum Erzeugen muss man sicher noch mal tiefer einsteigen.

    Viele Grüße, cebewee

    1 Teilnehmer(n) gefällt dieser Beitrag
Ansicht von 14 Beiträgen - 1 bis 14 (von insgesamt 14)