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]
<mailto:[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] <mailto:[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
