On Thu, Mar 4, 2010 at 12:45 PM, Andrea Aime <[email protected]> wrote:
> Simone Giannecchini ha scritto:
> >> Keeping the datastore in synch with imageio-ext is kind
> >> of important for any application that might use both, that
> >> is going to be possible only if the two share the same
> >> jars and the same native libraries.
> >> The datastore has been fixed and ported towards GDAL 1.7.1,
> >> afaik imageio-ext is going in the same direction?
> >
> > yes, imageio-ext 1.1 uses gdal 1.7.1
>
> As far as I can see it's still not released. But I guess
> we'll switch trunk to it as soon as the release is out,
> right?
>
>
Right.
> >> We have to agree on a groupId/artifact for the GDAL 1.7.1
> >> java bindings jar and push it onto some repo.
> >>
> >
> > not sure I am following here, can you explain?
>
> Well, the OGR datastore needs the gdal bindings around.
> However, it does not need imageio-ext raster stuff to be
> around, just the GDAL bindings jar generated by SWIG
> and the native libraries.
>
> So I think we should have the GDAL bindings jars published
> in a repo where both GeoTools and imageio-ext can use it.
> The group is could be org.gdal and the artifact id
> gdal-bindings, version 1.7.1
>
Actually, we have always deployed past gdal-bindings jars on both OpenGeo
and GeoSolutions repo as
it.geosolutions as group and imageio-ext-gdal-bindings as artifact id.
Anyway, we can arrange them as you suggest for the next 1.7.1 binding
artifact.
> >
> >> The current GDAL 1.7.1 build is simple enough, I hope that
> >> will make it easier for people to build their own customized
> >> OGR that still works with our stores/coverage readers (GDAL/OGR
> >> supports a ton of formats and we cannot really build them all).
> >> In particular I'm thinking about the GRASS formats, which
> >> I would very much like to see but that I understand would
> >> be a nuisance to build on all platforms (assuming imageio-ext
> >> keeps on building the native libraries, that is).
> >>
> >
> > we still have a small patch to apply for managing colormapped raster
> > data. I just asked daniele to check if this patch can be accepted
> > into the gdal codebase so that we don't have to bring it with us.
> >
> > Anyway, baseline is, yes, I agree we need to coordinate here but I
> > would really like to avoid more work coming from building the OGR
> > countepart, unless it is really small.
>
> Very much understandable. When you build the GDAL native libraries
> some basic OGR stores come into the package by default, or not?
>
Honestly, I haven't never played with the OGR things generated when building
the native libs.
Anyway, for testing purposes, I have just run a "ogrinfo --formats" using
the previously built 1.7.1 native libs and this is the output:
Supported Formats:
-> "ESRI Shapefile" (read/write)
-> "MapInfo File" (read/write)
-> "UK .NTF" (readonly)
-> "SDTS" (readonly)
-> "TIGER" (read/write)
-> "S57" (read/write)
-> "DGN" (read/write)
-> "VRT" (readonly)
-> "REC" (readonly)
-> "Memory" (read/write)
-> "BNA" (read/write)
-> "CSV" (read/write)
-> "GML" (read/write)
-> "GPX" (read/write)
-> "KML" (read/write)
-> "GeoJSON" (read/write)
-> "GMT" (read/write)
-> "ODBC" (read/write)
-> "PGeo" (readonly)
-> "PCIDSK" (readonly)
-> "XPlane" (readonly)
-> "AVCBin" (readonly)
-> "AVCE00" (readonly)
-> "DXF" (read/write)
-> "Geoconcept" (read/write)
-> "GeoRSS" (read/write)
-> "GPSTrackMaker" (read/write)
-> "VFK" (readonly)
Hope this helps,
Daniele
> If so, we can have those built while you're building the depds
> for imageio-ext, and if people need more, the build process for
> OGR is straightforward enough.
>
> Finger crossed about that patch, but in the ends it means the
> imageio-ext build of GDAL 1.7.1 will have to be custom and
> we'll have to wait at the very least for 1.7.2 to be able and use
> a normal GDAL build
>
> Cheers
> Andrea
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
-------------------------------------------------------
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
