[pgrouting-dev] [pgr_2.0] pgRouting 2.0 Update 2013-03-22

[Stephen Woodbridge]

On 3/22/2013 10:05 PM, Daniel Kastl wrote:
>
> On Sat, Mar 23, 2013 at 8:42 AM, Stephen Woodbridge
> <woodbri at swoodbridge.com <mailto:woodbri at swoodbridge.com>> wrote:
>
>     Hi all,
>
>     I continue to make progress on this. Next week I will be commuting
>     into Boston all week for the Code Sprint. I look forward to meeting
>     some of our colleagues there and continuing the efforts made so far.
>     I'm not looking forward 1 hr+ commute to get into Boston in the
>     mornings.
>
>
> Thanks a lot for lots of changes, Steve!
> Would have been nice to be in Boston as well next week, but commutation
> time from here is even longer ;-)
>
>
>     Today, I cleaned up the core/common/sql/* files, moved some cruft
>     that is not getting used elsewhere into a legacy file, renamed the
>     functions in topology and matching to have pgr_ prefix and pretty
>     much rewrote add_vertices_geometry() function. I also move functions
>     that were specific to an algorithm into their respect folders and
>     renamed files so they are more consistent.
>
>
> This is probably something Sandro can comment on, but is there any
> chance to make use of the new PostGIS topology support and topology in
> pgRouting. It's a different purpose, I know, just thinking loud.
> Renaming the create_vertex_id function is something I always thought to
> be important. The name already comes from pgDijkstra, though it always
> needed an extra explanation in the workshop as the name was a bit confusing.

No this is not appropriate. Maybe it could be used, but what we have is 
pretty simple and I don't think we want to make this overly complicated. 
That said, I happy to be persuaded to do it another way.

The nice thing about the new structure is the we now have a 
pgrouting_topology.sql and there is no reason someone can't supply an 
alternative set of functions.

> Have you seen Mario's attempts to rename the functions? Could be helpful
> for name finding.

I looked at it a while back. I will have to go look at it again. I have 
my own set of generic wrappers and some thoughts on how to do this, but 
more ideas are always good.

>     So far I have moved the following functions into the legacy file.
>     These will not get installed automatically and they will not be
>     maintained or tested and might just disappear. The real idea for the
>     legacy file is that we might want to build legacy wrappers that
>     simulate the old pre 2.0 behavior. This might be a job for another
>     contributor once the new api stabilizes.
>
>
> That's good.
>
>
>     Also, a few people have boldly step forward and tried on the new
>     code and reported back and I want to thank them for their feedback
>     and effort. The more this happens the better the code will
>     ultimately be, but things are very dynamic at the moment. I try to
>     keep the branch in a more or less buildable, installable state, and
>     to the extent I can functioning. If I find that I broke something, I
>     try to imediately fix and push the code back out. There is usually a
>     push every night or when I get a things stabilized. I think I pushed
>     code 3 or 4 times today. Did I mention this is dynamic? :)
>
>
> Yes, my Desktop notification for pgRouting news is already spinning ;-)
> If I find some time during the weekend I thought to move the
> documentation snippets into the right folders.
> Do you have any objection to use Sphinx to build the documentation? The
> website already uses it and the workshop as well.

No objection, I am starting to use rst for documentation, but have not 
gotten very far. So I would be happy if you want to move some do into 
the tree. I thinking that we could also add documentation in the sql 
files as tagged comments that could get extracted from the src can 
assembled into documentation, but that requires more code and standards 
so something for later maybe or maybe not.

-Steve