<div dir="ltr"><div>Hello all.<br></div>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:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span name="Even Rouault" class="">Even Rouault:</span><br></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>- gnm/frmts/gnm_frmts.h : I'm a bit concerned about exposing (installed<br>
header + CPL_DLL) an interface that has not yet been implemented. My intuition<br>
is that it might change once the first one or two implementations have been<br>
made. So maybe keep it internal/experimental for now. <br></div></blockquote><div><br></div><div>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?<br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-10 20:43 GMT+04:00 Dmitriy Baryshnikov <span dir="ltr"><<a href="mailto:bishop.dev@gmail.com" target="_blank">bishop.dev@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi, Imran.<br>
<br>
Yes, I think so. It depends on including GNM into GDAL. The python
binding using swig, so adding the java will be simple.<br>
<pre cols="72">Best regards,
Dmitry</pre>
09.09.2014 19:41, Imran Rajjad пишет:<br>
</div><div><div class="h5">
<blockquote type="cite">
<p>Will this be available for java bindings too?</p>
<div class="gmail_quote">On Sep 9, 2014 12:53 AM, "Even Rouault"
<<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> - gnm/frmts/gnm_frmts.h : I'm a bit concerned about
exposing (installed<br>
><br>
> > header + CPL_DLL) an interface that has not yet been
implemented. My<br>
> > intuition<br>
> > is that it might change once the first one or two
implementations have<br>
> > been made. So maybe keep it internal/experimental
for now.<br>
><br>
> I agree that the inclusion of the interfaces/capabilities
that can be (not<br>
> will be) extended in future is not a 100% good idea. I
hoped that someone<br>
> will be interested or even I will have time to implement
and extend<br>
> something of what I wrote at the "Future ideas" section
in my RFC. But we<br>
> do not know exactly will it be implemented or not. So:
(1) We can remove<br>
> for now all these interfaces "for future", which means to
leave only<br>
> GNMGdalNetwork and one analysing class. (2) Try to
implement these<br>
> capabilities: pgRouting for gnm_frmts.h and for example<br>
> GNMGdalStdRoutingAnalyser with some algorithm extension
(K shortest path).<br>
<br>
It's your call. Depend on how much time you have to implement
that, but we<br>
might go with the current state, if we clearly mark
experimental/unstabilized<br>
interfaces as such. Either by "hiding" them, or by
documentation if not<br>
possible.<br>
<br>
> - GNMManager::CreateConnectivity () : I'm confused by the
'native' term. In<br>
><br>
> > this method, native=false seems to imply the GDAL
"proprietary" network<br>
> > format<br>
> > that can work with any vector driver that has
similar capabilities than<br>
> > shapefile. Whereas in the RFC text, it seems to
imply the contrary (<br>
> > "network<br>
> > of ”GDAL-native” format").<br>
><br>
> Maybe I used it not correctly everywhere, but the general
idea is the<br>
> following: The term "native" corresponds to the existed
network formats (so<br>
> when we work with pgRouting network we work with its
native tables and<br>
> fields, rather than with GNMGdal- system layers), while
the GDAL-networks<br>
> are not "native" and more likely "common".<br>
><br>
<br>
Yes, that would be good if the language could be consistent
among the code and<br>
the RFC text. From your explanation, it seems that the text in
the RFC should<br>
be corrected. Yes GDAL-network is more a "common" or "generic"
network<br>
implementation.<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></blockquote></div><br></div>