[gdal-dev] Layer operations, a proposal

[Ari Jolma]

On 04/18/2012 05:28 PM, Howard Butler wrote:
> I'm excited by the functionality, but skeptical about having this specific functionality in OGR's core.  I don't want to be discouraging, but this seems like giant scope creep for OGR.

I agree that we disagree on the scope of GDAL ;) -- or at least think 
about it differently. My point of view to GDAL has always been more on 
the data abstraction (or common data model) side and I've seen the 
formats that drivers bring in a bonus basically. But of course it may be 
more valid to think about GDAL as a data access (and store) library - if 
I interpret your concern correctly.

GDAL's (GDAL+OGR) scope may indeed already be too broad (just think 
about how the algorithm side could be expanded).


>    It would seem as though there are tons of cases where things would degenerate quite quickly, especially with regard to doing these kinds of operations on data sources that variably support different access patterns. More bugs about pathological geometry overlay problems would become our responsibility. Also, this functionality already exists in GRASS almost verbatim, correct?

Basically I think these are pretty simple and generic algorithms and if 
it brings some issues to the surface with regard to data sources 
(drivers) then shouldn't that be a good thing (when thinking about the 
general quality of the code)? I'm pretty ignorant about the driver 
development but I'm a bit worried about the contract between drivers and 
the core - in my experience the capabilities and others are not always 
reported and implemented very methodologically. See for example this, 
which I stumbled upon just by working interactively: #4620

I'm looking at this from the point of view of interacting with data and 
especially enabling new tools. Maybe the best tool for this kind of 
analytical work would be PostGIS, and surely GRASS and QGIS and others 
have much of this too.


>
> Is it reasonable for this to start out as a commandline utility (ogralgebra or something) and see if some of the sharp points can be smoothed over before rolling this into core? I suppose this goes counter to your desire of having it accessible for SWIG languages though.

Yes, the basic (and sole) wish for me is to use it from Perl. In fact, I 
don't think that putting it into the core would be much better 
performance-wise, just availability-wise.

Putting this to the Perl bindings - although I don't assume it to be 
much code - is also kind of stretching the limits (there already is a 
few methods in there that do not exist in other bindings).

>
> In short, I can see how this is a great functionality boon for us, but I can also see that we might suffer for it a bit in terms of maintenance and headache associated with doing stuff that is not so much our forte.

Well, I think I'll make them anyway and publish the patch so that people 
can take a look and think. It would be a RFC anyway if and when it gets 
there.

Jeff, these are layer level methods and GEOS covers similar issues on 
geometry level, thus these are kind of one or two conceptual level 
higher and build on what GEOS delivers.

Best regards,

Ari

>
> Howard