[pgrouting-dev] Licensing for Co-development between
OpenGraphRouter and pgRouting
Anton Patrushev
anton.patrushev at georepublic.de
Sun Jun 5 23:58:18 EDT 2011
Hi Steve,
Are we planning to keep using BGL?
Anton.
On 6/3/11, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
> Hi Anton,
>
> I'm cc'ing Ashraf, not sure if he is on the list.
>
> This would be great and I would love to have you support and expertise
> on this. So first thing is I think we should pick one routing function,
> like Dijkstra just to keep it simple and replicate that in
> opengraphrouter and create pgRouting equivalent wrappers.
>
> The goal for this is to:
>
> 1. understand the process involved
> 2. allow Roni (Ashraf) to familiarize himself with postgresql server
> implementation
> 3. review new code from a GPL free point of view
>
> So for the Dijkstra I think we need to review the various layering in
> the code for example:
>
> 1. pgpsql function calls; input and output preserved
> these should be preserved for compatibility but we could add new ones to
> access new functionality
>
> 2. interface to opengraphrouter library
> 2a. what are the common public data structures, ie graph structures?
> 2b. what are the function input and outputs
> 2c. what if any are common utilities
> 2d. what is the C-API to opengraphrouter? is what this boils down to
>
> To some extent we could go through the existing pgRouting docs for much
> of this information on the pgRouting side. For the opengraphrouter side
> of things, I do not want to get to formal, and I think that writing 2-3
> of these functions will pretty quickly cause us to refactor into a
> useful api.
>
> We might want to move opengraphrouter to git-hub eventually, but I'm not
> very familiar with git-hub yet and still have to read the svn-git
> tutorial to do simple stuff.
>
> Thoughts?
>
> -Steve
>
> On 6/3/2011 2:04 AM, Anton Patrushev wrote:
>> Steve,
>>
>> I think it makes a lot of sense to use opengraphrouter (with
>> replicated pgRouting functionality) as a core and wrap it with command
>> line or PostGIS interfaces to have two different products. It kills
>> all rabbits with one shot - we still have GPLed pgRouting, we have its
>> functionality in opengraphrouter without any code sync problem, we
>> clean up and optimize code while replicating and finally we open a
>> possibility for other products to integrate our code.
>>
>> I'll be more than happy if somebody (Ashraf?) will do this job with my
>> and other's support. We can start with my "Cinnamon" studies (I think
>> I sent you the link or even the code some time ago). I had similar
>> idea those days, but it was abandoned due lack of resources.
>>
>>
>> Anton.
>>
>> On 6/3/11, Daniel Kastl<daniel at georepublic.de> wrote:
>>> 2011/6/3 Kishore Kumar<justjkk at gmail.com>
>>>
>>>> Hi,
>>>>
>>>> A quick question. I googled for PSC but couldn't find what it means. Is
>>>> it
>>>> a formal club of people working on a project?
>>>>
>>>
>>> Project Steering Committee
>>>
>>> It's something that OSGeo for example requires to apply for project
>>> incubation.
>>>
>>> Daniel
>>>
>>>
>>>
>>>>
>>>> Thanks& Regards,
>>>> J Kishore kumar.
>>>>
>>>>
>>>> On Fri, Jun 3, 2011 at 9:18 AM, Stephen Woodbridge<
>>>> woodbri at swoodbridge.com> wrote:
>>>>
>>>>> On 6/2/2011 11:18 PM, Daniel Kastl wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/6/3 Anton Patrushev<anton.patrushev at georepublic.de
>>>>>> <mailto:anton.patrushev at georepublic.de>>
>>>>>>
>>>>>>
>>>>>> > There was some talk about merging with PostGIS. Is anything
>>>>>> happening on that front or is that dead?
>>>>>>
>>>>>> Looks more like it's dead so far.
>>>>>>
>>>>>>
>>>>>> In my opinion it is not. Because it wasn't more than a first idea and
>>>>>> the earliest time would have been PostGIS 2.1 anyway. So I guess there
>>>>>> is still plenty of time and it's more up to pgRouting to do the
>>>>>> necessary work.
>>>>>>
>>>>>> If integration into PostGIS is a goal, then changing or adding a
>>>>>> license
>>>>>> isn't a topic, right?
>>>>>>
>>>>>
>>>>> I think the bigger question is is the purpose of integrating with
>>>>> PostGIS?
>>>>> This is not to challenge whether not not we should do this, only to get
>>>>> a
>>>>> better understanding of the reasons and to validate them.
>>>>>
>>>>> Do we think it will get us more development? How and Why do we believe
>>>>> this would happen?
>>>>>
>>>>> Do we think it would improve the product from a technical, marketing,
>>>>> management, funding or other point of view? How and Why do we believe
>>>>> this
>>>>> would happen?
>>>>>
>>>>> Some other assumptions that we might have?
>>>>>
>>>>> So there is a good president for project consoldation, in that
>>>>> mod_geocache and tinyOWS are small projects that are in the process of
>>>>> moving their provenance and management under the mapserver PSC. Both of
>>>>> these projects provide functionality that are commonly needed by
>>>>> mapserver
>>>>> users and smoothing the integration and coordinating releases adds some
>>>>> value to the mapserver users and hopefully some of the mapserver
>>>>> developers
>>>>> will get involved with these projects.
>>>>>
>>>>> So back to your question of licensing ... As long as the license is not
>>>>> in
>>>>> conflict with the PostGIS licensing then it should not be a problem.
>>>>> For
>>>>> example today you use boost graph which has a permissive license like
>>>>> MIT-X
>>>>> and this is not a problem. If we moved all the core algorithm
>>>>> development
>>>>> into something like opengraphrouter and then wrote pgRouting wrappers
>>>>> to
>>>>> integrate it it would be the same as what you have now.
>>>>>
>>>>> But there would be a huge advantage to the permissive licensing if you
>>>>> remember a while back there was some discussion with Ingres database,
>>>>> or
>>>>> we
>>>>> might want to integrate into mysql, sqlite, spatialite or just write
>>>>> standalone routing daemons. Having license flexibility makes this much
>>>>> easier.
>>>>>
>>>>> Ok, so we don't want to hassle with re-licensing pgRouting, then if we
>>>>> can
>>>>> prove that opengraphrouter code can be integrated into pgrouting then
>>>>> we
>>>>> could look at what to would take to replicate the existing
>>>>> functionality
>>>>> in
>>>>> opengraphrouter and wrap that back into pgrouting and then continue
>>>>> core
>>>>> algorithm development there and use the pgrouting PSC as the governing
>>>>> body
>>>>> for this work.
>>>>>
>>>>> We have a way to go to prove this, but Ashraf is willing to work on
>>>>> this
>>>>> to prove that we can do it.
>>>>>
>>>>> -Steve
>>>>>
>>>>> _______________________________________________
>>>>> pgrouting-dev mailing list
>>>>> pgrouting-dev at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pgrouting-dev mailing list
>>>> pgrouting-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Georepublic UG& Georepublic Japan
>>> eMail: daniel.kastl at georepublic.de
>>> Web: http://georepublic.de
>>>
>>
>>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Anton Patrushev
CTO
eMail: anton.patrushev at georepublic.de
Web: http://georepublic.de
Tel: +49 (089) 420 959 519
Sip: 1959519 at sipgate.de
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
More information about the pgrouting-dev
mailing list