Hello all. I'm trying to fix issues which were mentioned before in order to integrate GNM into GDAL 2.0. My question is about that issue:
Even Rouault: > - 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. > What's the correct way to mark some parts of GNM as internal? Just write in comments and documentation "this is for internal use for now" + not to add the headers to the "install" target, or I need something else to achieve this? 2014-09-10 20:43 GMT+04:00 Dmitriy Baryshnikov <[email protected]>: > Hi, Imran. > > Yes, I think so. It depends on including GNM into GDAL. The python binding > using swig, so adding the java will be simple. > > Best regards, > Dmitry > > 09.09.2014 19:41, Imran Rajjad пишет: > > Will this be available for java bindings too? > On Sep 9, 2014 12:53 AM, "Even Rouault" <[email protected]> > wrote: > >> >> > - 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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > _______________________________________________ > gdal-dev mailing > [email protected]http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
