Bienvenue! Inscrivez-vous et rejoignez notre communauté :)
  • Login:

Bienvenue sur Forum SIG - Systèmes d'Information Géographique et Géomatique.

Bienvenue sur le forumSIG. S'il s'agit de votre première visite, assurez vous de faire une recherche préalable dans les FAQ SIG. Vous devez vous inscrire avant de pouvoir poster.

Affichage des résultats 1 à 6 sur 6
  1. #1
    Biblioman
    Date d'inscription
    mai 2005
    Localisation
    Villeurbanne
    Âge
    36
    Messages
    3 293

    Par défaut Bientôt une API pour les geodatabases fichiers open source ?

    Depuis 2012, il existe une API permettant d'utiliser les geodatabases fichiers, cf http://www.forumsig.org/showthread.p...light=fgdb+api

    Fallait bien que cela arrive un jour, un gentil 'hacker' est en train de décortiquer l'API, dans l'idée d'en permettre une implémentation totalement open source.

    Les détails en VO: http://erouault.blogspot.ca/2013/10/...ngineered.html
    En trad auto:
    mercredi 9 octobre 2013

    Format FileGDB ingénierie inverse

    Pour ceux qui ne peuvent pas attendre, vous pouvez vous précipiter directement à la résultante spécification . Attention: ce travail est en cours!

    Maintenant, l'introduction. FileGDB est le format de base de données géoréférencées du fichier ESRI utilisé nativement par ArcGIS pour stocker des ensembles de données dans un répertoire du système de fichiers.

    Depuis la version 1.9 de GDAL / OGR , un conducteur FileGDB existe et donne lecture / mise à jour / support de création pour FileGDB sources de données, mais il a quelques limitations:

    • il s'appuie sur un logiciel gratuit (comme dans la bière), mais la bibliothèque closed-source, l'API FileGDB. Pas l'idéal philosophique et pratique.
    • l'API FileGDB est limitée à l'ouverture FileGDB sources de données créée par ArcGIS 10 ou plus tard, mais pas celles qui sont créées par les versions antérieures.
    • l'API FileGDB a quelques bugs qui l'empêche d'ouvrir les couches de FileGDB valides, par exemple si le SRS est une projection personnalisée , et les utilisateurs peuvent simplement attendre une version du fournisseur qui finira par corriger.
    • il semble avoir (inutile) quadratique performances lorsque le nombre de champs se développer, notamment avec certaines sources de données US Census qui ont plus de 1800 domaines, ce qui rend leur lecture très lente.

    Alors, j'ai décidé d'ouvrir mon éditeur hexadécimal préféré et regardez de plus près ce qu'il ya dans les entrailles des fichiers trouvés dans un répertoire de gdb.. Depuis les extensions, il est évident que les fichiers gdbtablx. Gdbtable et. Devraient être le plus intéressant.

    A. Gdbtable correspond à une couche / table, et contient la description des champs (nom, type, largeur, etc.), L'information géospatiale (type de géométries, SRS, mesure) ainsi que le contenu des lignes / fonctions. C'est l'équivalent d'un. Shp et. Dbf des fichiers de formes. L'. Gdbtablx est un indice qui contient le décalage de chaque rangée de l'. Gdbtable. C'est l'équivalent du fichier. Jpeg de fichiers de formes.

    À ma grande surprise, le processus de reverse engineering est allé assez vite. Générer des couches très triviales avec l'API FileGDB, avec de petites variations, et d'analyser les différences beaucoup aidé. La plupart des types de données peuvent être devinés d'une manière évidente avec un éditeur hexadécimal (little-endian int16/int32/IEEE 754 float64/UTF-16 cordes). Quelques détails techniques non évidents:

    • l'utilisation d'un codage de longueur variable pour les entiers (qui AFAICS est identique au protocole de base de la mémoire tampon 128 varints ), surtout pour les coordonnées (et ainsi de spécifier la longueur des chaînes). Le premier triplet de coordonnées d'une géométrie est codé sous la forme «absolue» (qui doit être ultérieurement excentrée et étendu par des constantes décrites dans la définition du champ de la géométrie). Toutes les coordonnées suivantes sont codés comme étant la différence avec les coordonnées précédentes.
    • comprendre comment datetimes sont encodés m'a fallu une étonnante longtemps, par rapport au résultat: il est tout simplement le nombre de jours (éventuellement avec décimales) depuis 1899/30/12 00:00:00, codé comme un float64.
    • comment les indicateurs indiquant l'absence ou la présence de champs travaillées. La partie la plus délicate a été de comprendre que seuls les champs nullables sont représentées dans le domaine bit.

    J'ai développé un petit script Python qui déverse le contenu d'un fichier gdbtable. (en utilisant son fichier de compagnie. d'gdbtablx) et, jusqu'à présent, elle parvient à vider avec succès tous les fichiers. gdbtable j'ai essayé, deux tables techniques ( GDB_xxxxxx) et les tables utilisateur (couches vectorielles), y compris à partir de sources de données GDB qui ne peut pas être lu par l'API FileGDB (ancien v9.x sources de données, ou sources de données avec des projections personnalisées).

    Juste un exemple sur une couche de l'échantillon distribué avec l'API FileGDB (peut-être seulement sexy aux yeux des fans d'utilitaires en ligne de commande):

    $ Python dump_gdbtable.py / home/even/FileGDB_API/samples/data/Shapes.gdb/a00000013.gdbtable
    nfeaturesx = 233
    nCaractéristiques = 233
    header_offset = 40
    header_length = 627
    layer_geom_type = 3
    polyligne
    nfields = 6

    nbcar = 8
    name = OBJECTID
    nbcar_alias = 0
    alias =
    type = 6 (objectid)
    magic1 = 4
    magic2 = 2
    nullable = 0

    nbcar = 5
    name = Forme
    nbcar_alias = 0
    alias =
    type = 7 (géométrie)
    magic1 = 0
    magic2 = 7
    wkt =
    MagIC3 = 7
    xorigin = -400,000000000000000
    yorigin = -400,000000000000000
    xyscale = 11258999068426,238281250000000
    zorigin = -10,000,000000000000000
    zScale = 10,000,000000000000000
    morigin = -10,000,000000000000000
    mscale = 10,000,000000000000000
    xytolerance = 0,000000008983153
    ztolerance = 0,001000000000000
    mtolerance = 0,001000000000000
    xmin = -158,090073924418533
    ymin = 21,277505248718398
    xmax = -67,781176946816174
    ymax = 62,145206966737987
    Magic4 = 3
    25,6301473254
    79,4534567087
    246,305715797
    nullable = 1

    nbcar = 9
    Nom = ROUTE_NUM
    nbcar_alias = 0
    alias =
    type = 4 (chaîne)
    width = 8
    flag = 5
    magie = 0
    nullable = 1

    nbcar = 10
    name = DIST_MILES
    nbcar_alias = 0
    alias =
    type = 2 (float32)
    width = 4
    flag = 5
    magie = 0
    nullable = 1

    nbcar = 7
    Nom = DIST_KM
    nbcar_alias = 0
    alias =
    type = 2 (float32)
    width = 4
    flag = 5
    magie = 0
    nullable = 1

    nbcar = 12
    name = Shape_Length
    nbcar_alias = 0
    alias =
    type = 3 (float64)
    width = 8
    flag = 3
    magie = 0
    nullable = 1


    FID = 1
    feature_offset = 671
    blob_len = 17880
    flags = [224]
    geom_len = 17856
    GEOM_TYPE = 3
    polyligne
    nb_total_points: 1530
    nb_geoms: 3
    Minx = -118,485959167123966
    Miny = 29,394035111730691
    maxx = -81,682130704462821
    Maxy = 34,087306274650871
    NB_POINTS [0] = 35
    NB_POINTS [1] = 907
    [1] -118,485959167123966 34,014739115964872
    [2] -118,475133048781629 34,022692037809506
    [...]
    [34] -118,226133325056821 34,028554888549152
    [35] -118,220945200338008 34,033902601472484

    [1] -118,213980138991928 34,055149589953267
    [2] -118,206975896201286 34,053569604619412
    [...]
    [906] -95,292373751724142 29,777536210780305
    [907] -95,284004512870197 29,777996158193261

    [1] -95,258536827702414 29,774727145411369
    [2] -95,237242253618717 29,773808093496442
    [...]
    [587] -81,690798069370828 30,320550259572705
    [588] -81,682130704462821 30,321330304058421

    Champ ROUTE_NUM: "I10"
    DIST_MILES sur le terrain: 2449.120117
    Champ DIST_KM: 3941.479980
    Shape_Length de champ: 40.473531

    [...]

    Prochaines étapes?

    • Un pilote GDAL / OGR application du présent cahier des charges, sans aucune dépendance à l'égard des tiers, ce serait cool, n'est-ce pas? Probablement en lecture seule dans l'état actuel des connaissances. Mais il serait susceptible de résoudre tous les limites du pilote existant et offrir les avantages suivants: libre et open source, FileGDB compatibilité v9.x, aucune limitation du SRS. Astuce: financement serait le bienvenu pour aider à la développer .
    • Comprendre la signification de certains champs "magiques" qui pourraient avoir une importance pratique.
    • J'ai rencontré une source de données avec des données raster. L'utilitaire de sauvegarde aurait besoin d'amour supplémentaire pour faire face aux champs binaires, que je n'ai pas enquêter plus avant. Mais peut-être les ensembles de données raster FileGDB peuvent être lus aussi bien.
    • Pour braves gens: déchiffrer le format des autres catégories de fichiers qui ont été laissés de côté:. Gdbindexes, freelist, TablesByName.atx, CatItemsByPhysicalName.atx, CatItemsByType.atx, FDO_UUID.atx, spx....... Divers indices doivent être là, certains potentiellement pour la création / mise à jour des opérations. Cela pourrait être beaucoup plus difficile de deviner que le. Gdbtable lui-même, si l'on tient compte de la difficulté a été le reverse engineering du fichier de formes. index spatial SBN .





    Home is where the .arc is...
    Propos sous license Beerware !!!

  2. #2
    Modérateur et rédacteur Supporter(rice)


    Date d'inscription
    octobre 2005
    Localisation
    Louvain-la-neuve
    Emploi
    Géologue
    Organisme
    Université Catholique de Louvain - Région Wallonne
    Messages
    2 652

    Par défaut Re : Bientôt une API pour les geodatabases fichiers open source ?

    Traiter Even Rouault de gentil hacker....
    "Caminante, no hay camino, el camino se hace al andar" A. Machado

  3. #3
    Biblioman
    Date d'inscription
    mai 2005
    Localisation
    Villeurbanne
    Âge
    36
    Messages
    3 293

    Par défaut Re : Bientôt une API pour les geodatabases fichiers open source ?

    Citation Envoyé par gene Voir le message
    Traiter Even Rouault de gentil hacker....
    Sans insulte, quand je vois des gars sortir l'éditeur hexadecimal, je les range dans la catégorie des hackers...
    Home is where the .arc is...
    Propos sous license Beerware !!!

  4. #4
    Modérateur et rédacteur Supporter(rice)


    Date d'inscription
    octobre 2005
    Localisation
    Louvain-la-neuve
    Emploi
    Géologue
    Organisme
    Université Catholique de Louvain - Région Wallonne
    Messages
    2 652

    Par défaut Re : Bientôt une API pour les geodatabases fichiers open source ?

    Bon, je suis donc un hacker...
    "Caminante, no hay camino, el camino se hace al andar" A. Machado

  5. #5
    Admin' Général Supporter(rice)

    Date d'inscription
    septembre 2003
    Localisation
    ...dans mon TARDIS
    Organisme
    Bad Wolf
    Âge
    38
    Messages
    9 710

    Mes réseaux sociaux

    Follow Le Docteur On Twitter

    Par défaut Re : Bientôt une API pour les geodatabases fichiers open source ?

    Citation Envoyé par gene Voir le message
    Bon, je suis donc un hacker...
    J'en était sur !
    >>>>>>>> Pas d'assistance technique par email ou mp : le forum est là pour ça <<<<<<<<<<<<


  6. #6

    Date d'inscription
    mars 2013
    Localisation
    Nouvelle Calédonie
    Emploi
    Géomatechnicien
    Âge
    37
    Messages
    10

    Par défaut Re : Bientôt une API pour les geodatabases fichiers open source ?

    Chapeau!
    J'ai moi même un problème d'encodage sur certain champs. Pour passer les tables vers postgis et je me demande si ça ne serait pas du à l'utf16...

 

 

Discussions similaires

  1. Réponses: 3
    Dernier message: 19/07/2011, 13h35
  2. [Autres] Meilleur logiciel open source pour tracage réseau
    Par Christophe58 dans le forum Assistance et Programmation
    Réponses: 2
    Dernier message: 09/06/2011, 14h46
  3. [Débat] L'Open Source, véritable alternative pour les SIG ?
    Par Le Docteur dans le forum Théorie des SIG - Géomatique
    Réponses: 1
    Dernier message: 10/04/2006, 13h44
  4. [WebMapping] SIG Open Source pour portail de travail collaboratif
    Par malvarez dans le forum Assistance et Programmation
    Réponses: 2
    Dernier message: 21/03/2006, 15h26
  5. [Marché] Logiciel open source pour la gestion d'accès bâtiment
    Par 2020 dans le forum Théorie des SIG - Géomatique
    Réponses: 12
    Dernier message: 02/09/2004, 08h31

Les tags pour cette discussion

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •