[gdal-dev] RFC 48: Geographical networks support

Dmitriy Baryshnikov bishop.dev at gmail.com
Wed Sep 10 09:43:35 PDT 2014


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" <even.rouault at spatialys.com 
> <mailto:even.rouault at spatialys.com>> 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
>     gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140910/19e54f88/attachment.html>


More information about the gdal-dev mailing list