GeoTools
  1. GeoTools
  2. GEOT-4507

Improve setup of imageMosaicJDBC-PGRaster

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 12-beta
    • Labels:
      None

      Description

      Right now, in order to config an imageMosaic JDBC against PGRaster DB there are several steps to be performed:
      1) use gdal_retile to create tiles for images
      2) insert tiled data as new table (one for level) into PGRaster using raster2pgsql scripts invokation
      3) create a table containing level information (reference table, envelope, resolutions)
      4) insert table names into the newly created table
      5) create 3 XML config files with JDBC mapping, coverage properties, table mapping
      6) configure the mosaic.

      It would be good to have some automagic way to do steps 2 through 6 with minimal user intervention.

      As an instance, it would be great if we could just provide the location of the folder containing tiled images (levels), as well as a set of some additional parameters (table name prefix, mosaic name, coverage name, DB credentials) and let the imageMosaicJDBC do all these steps automatically.

        Activity

        Hide
        Christian Mueller added a comment -
        Those steps have to be performed for all kinds of rasters stored in a jdbc database. (e.g Oracle GeoRaster, BLOBs combined with geometries,..).

        IMHO, I would vote for a new module called "imageMoasicJDBC-ng" with the following features

        1) Use the geotools JDBCDataStore
        2) Use the new coverage reader capable of handling multiple overages
        3) In case of Oracle GeoRaster, fetch meta information from system catalogs
        4) In case of postgis raster, fetch meta data from the result of raster2pgsql
        5) If necessary, create the meta tables on the fly
        6) Add temporal support
        .......

        The list is not complete.

        Of course it is possible to enhance the existing module, but the enhancement should work for any kind of jdbc raster and this requires online tests for

        DB2 using Geometries
        Oracle using Geometries
        Oracle GeoRoaster
        PostGis using Geometries
        PostGis Raster
        MySql using Geometries
        MSqlServer using Geomtries

        This is a lot of action.


        Show
        Christian Mueller added a comment - Those steps have to be performed for all kinds of rasters stored in a jdbc database. (e.g Oracle GeoRaster, BLOBs combined with geometries,..). IMHO, I would vote for a new module called "imageMoasicJDBC-ng" with the following features 1) Use the geotools JDBCDataStore 2) Use the new coverage reader capable of handling multiple overages 3) In case of Oracle GeoRaster, fetch meta information from system catalogs 4) In case of postgis raster, fetch meta data from the result of raster2pgsql 5) If necessary, create the meta tables on the fly 6) Add temporal support ....... The list is not complete. Of course it is possible to enhance the existing module, but the enhancement should work for any kind of jdbc raster and this requires online tests for DB2 using Geometries Oracle using Geometries Oracle GeoRoaster PostGis using Geometries PostGis Raster MySql using Geometries MSqlServer using Geomtries This is a lot of action.
        Hide
        Daniele Romagnoli added a comment -
        Hi Christian,
        we got a mandate for a specific improvement of the PostGis Raster support, in order to simplify a bit the steps required to configure such a store.
        This is why the focus of this JIRA is centered on that specifc improvement and we didn't discussed anything special about integrating it with the multiple coverages modules or refactoring it as per your suggestion.
        I was thinking about an Hint containing a JDBGPostgisRasterConfiguration bean which trigger some new configuration code only in that PGRaster case so that the old code will continue working the same way without regressions for the other formats.

        Daniele



        Show
        Daniele Romagnoli added a comment - Hi Christian, we got a mandate for a specific improvement of the PostGis Raster support, in order to simplify a bit the steps required to configure such a store. This is why the focus of this JIRA is centered on that specifc improvement and we didn't discussed anything special about integrating it with the multiple coverages modules or refactoring it as per your suggestion. I was thinking about an Hint containing a JDBGPostgisRasterConfiguration bean which trigger some new configuration code only in that PGRaster case so that the old code will continue working the same way without regressions for the other formats. Daniele
        Hide
        Simone Giannecchini added a comment -
        Ciao Christian,
        as Daniele correctly pointed out we do not have a mandate to create a new module or to work on anything beyond simplifying Postgis Raster support.

        I have suggested Daniele to move the discussion to the mailing list to make sure the work he does gets accepted by the module maintainer (you :)).
        Show
        Simone Giannecchini added a comment - Ciao Christian, as Daniele correctly pointed out we do not have a mandate to create a new module or to work on anything beyond simplifying Postgis Raster support. I have suggested Daniele to move the discussion to the mailing list to make sure the work he does gets accepted by the module maintainer (you :)).
        Hide
        Daniele Romagnoli added a comment -
        Show
        Daniele Romagnoli added a comment - Pull request ready: https://github.com/geotools/geotools/pull/533

          People

          • Assignee:
            Daniele Romagnoli
            Reporter:
            Daniele Romagnoli
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: