> - gnm/frmts/gnm_frmts.h : I'm a bit concerned about exposing (installed > > > header + CPL_DLL) an interface that has not yet been implemented. My > > intuition > > is that it might change once the first one or two implementations have > > been made. So maybe keep it internal/experimental for now. > > I agree that the inclusion of the interfaces/capabilities that can be (not > will be) extended in future is not a 100% good idea. I hoped that someone > will be interested or even I will have time to implement and extend > something of what I wrote at the "Future ideas" section in my RFC. But we > do not know exactly will it be implemented or not. So: (1) We can remove > for now all these interfaces "for future", which means to leave only > GNMGdalNetwork and one analysing class. (2) Try to implement these > capabilities: pgRouting for gnm_frmts.h and for example > GNMGdalStdRoutingAnalyser with some algorithm extension (K shortest path).
It's your call. Depend on how much time you have to implement that, but we might go with the current state, if we clearly mark experimental/unstabilized interfaces as such. Either by "hiding" them, or by documentation if not possible. > - GNMManager::CreateConnectivity () : I'm confused by the 'native' term. In > > > this method, native=false seems to imply the GDAL "proprietary" network > > format > > that can work with any vector driver that has similar capabilities than > > shapefile. Whereas in the RFC text, it seems to imply the contrary ( > > "network > > of ”GDAL-native” format"). > > Maybe I used it not correctly everywhere, but the general idea is the > following: The term "native" corresponds to the existed network formats (so > when we work with pgRouting network we work with its native tables and > fields, rather than with GNMGdal- system layers), while the GDAL-networks > are not "native" and more likely "common". > Yes, that would be good if the language could be consistent among the code and the RFC text. From your explanation, it seems that the text in the RFC should be corrected. Yes GDAL-network is more a "common" or "generic" network implementation. -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev