[pgrouting-dev] Licensing for Co-development
between OpenGraphRouter and pgRouting
Stephen Woodbridge
woodbri at swoodbridge.com
Fri Jun 3 10:38:26 EDT 2011
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
>>
>
>
More information about the pgrouting-dev
mailing list