<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [gdal-dev] Layer operations, a proposal</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Ari,<BR>
<BR>
For what it's worth, I'd sure love to see this functionality - essentially ArcInfo workstation like capabilities. I don't have any opinion on whether it's core or not in GDAL, but when I started doing something similar with Python (a couple years ago) I found that GEOS didn't play nicely with GDAL so I gave up. <BR>
<BR>
It was probably my own fault (or the bindings?), but I mention it because even a set of Python scripts would be remarkably useful - and keeping them outside of GRASS or other apps lowers the bar for adoption.<BR>
<BR>
My two cents,<BR>
Tyler<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: gdal-dev-bounces@lists.osgeo.org on behalf of Ari Jolma<BR>
Sent: Wed 4/18/2012 8:09 AM<BR>
To: gdal-dev@lists.osgeo.org<BR>
Subject: Re: [gdal-dev] Layer operations, a proposal<BR>
<BR>
On 04/18/2012 05:28 PM, Howard Butler wrote:<BR>
> 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.<BR>
<BR>
I agree that we disagree on the scope of GDAL ;) -- or at least think<BR>
about it differently. My point of view to GDAL has always been more on<BR>
the data abstraction (or common data model) side and I've seen the<BR>
formats that drivers bring in a bonus basically. But of course it may be<BR>
more valid to think about GDAL as a data access (and store) library - if<BR>
I interpret your concern correctly.<BR>
<BR>
GDAL's (GDAL+OGR) scope may indeed already be too broad (just think<BR>
about how the algorithm side could be expanded).<BR>
<BR>
<BR>
> 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?<BR>
<BR>
Basically I think these are pretty simple and generic algorithms and if<BR>
it brings some issues to the surface with regard to data sources<BR>
(drivers) then shouldn't that be a good thing (when thinking about the<BR>
general quality of the code)? I'm pretty ignorant about the driver<BR>
development but I'm a bit worried about the contract between drivers and<BR>
the core - in my experience the capabilities and others are not always<BR>
reported and implemented very methodologically. See for example this,<BR>
which I stumbled upon just by working interactively: #4620<BR>
<BR>
I'm looking at this from the point of view of interacting with data and<BR>
especially enabling new tools. Maybe the best tool for this kind of<BR>
analytical work would be PostGIS, and surely GRASS and QGIS and others<BR>
have much of this too.<BR>
<BR>
<BR>
><BR>
> 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.<BR>
<BR>
Yes, the basic (and sole) wish for me is to use it from Perl. In fact, I<BR>
don't think that putting it into the core would be much better<BR>
performance-wise, just availability-wise.<BR>
<BR>
Putting this to the Perl bindings - although I don't assume it to be<BR>
much code - is also kind of stretching the limits (there already is a<BR>
few methods in there that do not exist in other bindings).<BR>
<BR>
><BR>
> 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.<BR>
<BR>
Well, I think I'll make them anyway and publish the patch so that people<BR>
can take a look and think. It would be a RFC anyway if and when it gets<BR>
there.<BR>
<BR>
Jeff, these are layer level methods and GEOS covers similar issues on<BR>
geometry level, thus these are kind of one or two conceptual level<BR>
higher and build on what GEOS delivers.<BR>
<BR>
Best regards,<BR>
<BR>
Ari<BR>
<BR>
><BR>
> Howard<BR>
<BR>
_______________________________________________<BR>
gdal-dev mailing list<BR>
gdal-dev@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>