[gdal-dev] RFC 48: Geographical networks support

[Mikhail Gusev]

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 <bishop.dev at gmail.com>:

>  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>
> 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
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttp://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/20150324/ed183edd/attachment.html>