Jason Roberts wrote: > A while back, Mateusz asked this: >> Yes. Also, most applications I've seen using OGR do define their own >> data models and translate OGRFeature to features of their own types. >> Perhaps it would be interesting to know why they don't use OGRFeature >> as a part of their data model, what's missing... > > I am currently evaluating whether or not I should use OGRFeature directly > in a data model, or wrap it. Without nullability, I am probably inclined > to wrap it. As I have mentioned previously on gdal-dev, I'm trying > to build something that wraps OGR and ArcGIS APIs behind a common > abstraction, to allow development of tools that work with both.
I have no interest in trying to convince you to not to do it, but my name appeared, so I feel entitled to share comment. I'd be careful as abstractions of abstractions can easily lead to fat beasts which can do everything, but are complex as hell where nobody understands what is what and how it actually works. Wrapper, namely adapter pattern, usually means translation of one interface to another, likely to interface which has common denominator with something else. It is about structure of software components. However, translation between interfaces, does not mean translation between semantics. The latter problem belongs to domain of data models and ORM. You will most likely have to deal with both problems. The API translation should be a straightforward task. ORM usually introduces the whole pile of complexity (see software pieces like FDO). My point is, I doubt there is a point in developing such thing. Best regards, -- Mateusz Loskot http://mateusz.loskot.net _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
