Good proposal. But what about this which is more in our hands: Just wrap GDAL/OGR to become an ArcGIS extension which can simply added as a free alternative to the "Interoperability Extension"? And if the C libraries are in the way - and anyway - why not write a standalone Python library for reading Spatialite like Shapely reads Shapefile (Sean are you listening)?
Yours, S. 2012/4/10 Eric Wolf <[email protected]>: > One huge step towards "fixing" the interoperability problem would be if Esri > managed to "more loosely" couple ArcGIS and GDAL/OGR. > > Imagine if you could rebuild GDAL.DLL and drop it into the ArcGIS > installation path giving ArcGIS all the up-to-date goodness of the current > version of GDAL/OGR. > > Then, when someone wrote drivers for a new format in GDAL/OGR, they > "magically" worked with ArcGIS. This wouldn't reduce the value of ArcGIS on > iota. > > Imagine if Esri did the same thing with Python - oh the joys of being on 3.3 > (or even 2.7 for that matter). Again, no conceivable harm would come to > Esri. > > Jack? Are you listening? > > If you could give me one thing "at" 10.1 (or 10.2, I'd even wait for 11), it > would be this - make your programmers work a little harder so that life > would be a lot easier for the rest of us! > > > -Eric > > -=--=---=----=----=---=--=-=--=---=----=---=--=-=- > Eric B. Wolf 720-334-7734 > > > > > > On Mon, Apr 9, 2012 at 4:46 PM, Stefan Keller <[email protected]> wrote: >> >> 2012/4/9 Frank Warmerdam <[email protected]>: >> > 2012/4/9 Stefan Keller <[email protected]>: >> >> Private development: That's the current show stopper. That's why I >> >> proposed it to become an OSGEO project. That's also where the "SQLite >> >> Provider" comes in but which I found only used (half-hartedly?) in >> >> FDO. >> > >> > Folks, >> > >> > For what it's worth at one point the FDO guys, and EvenR and I >> > on behalf of GDAL/OGR tried to nail down details of how to use >> > Sqlite as a geodatabase and we hoped in way that was interoperable >> > with SpatialLite. I'm not exactly clear on the state of things now. >> > I know that the OGR Sqlite driver will now try and use spatialite >> > functions including the spatial index if available. I'm not sure if >> > it still works properly against spatialite databases without actually >> > having spatiallite linked in. >> > >> > My *ambition* was a well specified schema in Sqlite so that >> > apps could depend on it for interoperability with or without having >> > spatiallite available. However the spatialite project didn't seem to >> > want to get tied down to something stable and I lost interest. >> > >> > I still like the idea of sqlite as a geodatabase but I haven't the >> > fortitude to advocate strongly for how I think it ought to work. >> > >> > Best regards, >> >> There was some communication outside geowanking so I'm citing >> partially to summarize: >> >> 2012/4/9 Even Rouault <[email protected]> answered: >> > The state of the OGR Spatialite support is quite good, especially since >> > OGR >> > 1.9.0. I think Frank's concern is probably the fact that the Spatialite >> > project is a bit a one-man-show, where the community is more a community >> > of >> > passive users without much to say in the evolution of the project. >> > Although I >> > think it has improved a bit, and has attracted at least another active >> > contributor recently. But I remember a post of Sandro Furieri where he >> > wasn't >> > very interested into making it a OSGeo project. >> > >> > Performance wise, I find it to be one of the best solutions when doing >> > spatial >> > requests on datasets not requiring something big like the >> > PostgreSQL/PostGIS >> > pair. >> >> And then: >> >> > I've never played with the FDO spatial extension, so I cannot comment on >> > that >> > side. FDO is such a pain to build that I've never managed to do it... >> > >> > The key is to have an efficient spatial index. Spatialite does that by >> > using the >> > R-Tree capabilities of "recent" Sqlite versions, and by using triggers >> > that >> > update it consistently. >> > >> > As far as the spatialite geometry blob format is concerned, it is >> > documented, >> > ... >> >> So to conclude so far I can state the following about the initial >> question: >> * To me, the SQlite 3 format has potential to become the "Shapefile of >> the future" covering the Shapefiles's use case which I call a "single >> binary desktop exchange format for geospatial data". >> * There are two alternatives as spatial extensions, Spatialite and SQlite >> FDO. >> * Obviously, there has never been made a comparison between both and >> it seems that both communities don't know each other. >> >> To me, Spatialite obviously is more promising because it simply has >> more coverage and support. The concerns about the support in OGR and >> being a one-man show seem to be sorted out. >> Still, some issues remain to me, namely: >> 1. There's a recurring argument that Spatialite has it's "built'in" >> GIS functionality. As a matter of fact, some Spatialite proponents >> insist that this is the foremost argument. But what's this about here >> is just a "desktop exchange format" for Simple Features vector data. >> 2. So far I have'nt heard anything from FDO community. At least OSGeo >> and Autodesk should have an interest. I'd like to give them another >> chance in order to get them in the boat. >> >> Yours, S. >> >> _______________________________________________ >> Geowanking mailing list >> [email protected] >> http://geowanking.org/mailman/listinfo/geowanking_geowanking.org > > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org > _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
