Jason Roberts wrote:
Ragi,
Thanks for your thoughts. I know what you are saying; no need to create a
another useless layer. But by adopting one or the other APIs, I would get
locked in to whatever that API decided to support, with no way to work
around it other than to hack on a private copy of that particular API.
The "is nullable" topic is a case in point. Coming from the database world,
I personally think it is very useful to be able to interrogate a schema to
determine if a field is nullable, and in existing GIS tools I do it for
various reasons. But Frank W is lukewarm to adding it to OGR. Neither of us
is right or wrong, necessarily, but as owner of OGR (at least way more than
me), Frank will probably decide whether OGRFieldDefn deserves to be extended
to include IsNullable (or maybe it would be OGRLayer::FieldIsNullable). I
must live by that decision if I adopt OGR wholesale as my internal API.
Jason,
I would stress that it was important for GDAL to move to a project steering
committee model under OSGeo exactly so that things would not be unduely
constrained by what I was hot or cold about. If you can a project developer
who is hot on the idea, and is willing to try and stick-handle an RFC on the
topic through, then the idea can get implemented. But it is a non-trivial
change (once you update lots of drivers, implement tests, docs, etc) and
so it will take resources (volunteer, yours or otherwise) to make it happen.
Given the breadth of environments you would eventually like to write tools
for, it is *possible* you might want your own higher level API but I think
you would be better off looking for simplier, rather than more complicated
features or else your tools will still not work across everything.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
