[gdal-dev] Adopt RFC48: Geographical networks support
bishop.dev at gmail.com
Fri Jul 31 13:44:56 PDT 2015
31.07.2015 22:54, Stephen Woodbridge пишет:
> On 7/31/2015 2:51 PM, Dmitry Baryshnikov wrote:
>> Hi everybody,
>> The motion of RFC48 has been adopted with support from PSC members
>> JukkaR, TamasS and EvenR.
>> The code merged in trunk now (r29585). Let me know if issues arise.
>> Also the RFC
>> (https://trac.osgeo.org/gdal/wiki/rfc48_geographical_networks_support) and
>> RFC common page (https://trac.osgeo.org/gdal/wiki/RfcList) were
> This looks very interesting. I have a few questions which might get
> added to the futures if they are not already supported.
> Are there any drivers yet? Which?
> * like read/write OSM data or pgRouting tables
By now only two drivers present - both implements generic (or GDAL)
network. The pgRouting driver in plans. The GNMNetwork API let write
features to the network and connect them. See
> Are there plans to support turn restrictions?
> * OSM defines edge-node-edge restrictions AND edge-edge-edge-...
> * currently OSRM only supports edge-node-edge restrictions
> * pgRouting supports edge-edge-edge-... restrictions
In GNM you can block edge and connection (node), but in generic network.
In other drivers i.e. pgRoputing, OSRM, graphopper etc. it'll depends on
implementation. Also the API of GNMNetwork class may be change (so the
compiling of GNM is disabled by default).
> There is a real need to be able to move network data between pgRouting
> and OSRM. The osm2pgrouting tool is undergoing some enhancements
> during the current GSoC. There is also a need to be able to move
> pgrouting tables to OSM pbf files so we can load them into OSRM and
> this seems like an excellent use case for this.
We can begin thinking about network2network tool after the couple of
network drivers will be implemented. The help is welcome, as I plan now
to concentrate on cmake for GDAL.
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev