[pgrouting-users] Table location

Stephen Woodbridge woodbri at swoodbridge.com
Sat Jan 29 13:53:43 EST 2011


On 1/29/2011 12:36 PM, Dan Putler wrote:
> Hi Steve,
>
> Have you submitted a patch with the changes? It seems like a good change.

Nope, I never got around to patches, but after looking into the problem 
again, I may have been mistaken. The only place that 'public' is 
explicity used is in "core/sql/routing_topology.sql" in:

_srid := Find_SRID('public','vertices_tmp','the_geom');

And this should be ok, unless you move the location of 'vertices_tmp' to 
another schema.

I have rewritten a lot of the wrapper code for my own purposes and it 
might not be general purpose anymore.

For example in the piece above, I moved the query query for srid out of 
point_to_id() into assign_vertex_id() and use the code:

EXECUTE 'SELECT srid FROM geometry_columns WHERE f_table_name='|| 
quote_ident(geom_table) INTO srid;

Then I pass the srid into point_to_id() because the srid should not 
change from point to point. And while psql probably caches the query, 
there is no need to compute it multiple times.

As some point when I have some spare time I will review my code changes 
and propose a set a patches back to the source tree. One of the other 
big changes I made for my purposes, was to rationalize the the wrapper 
API calls so that they are nearly identical except for the name. This 
makes if much easier to write generic code from an application point of 
view there you only need to change the function name to change the 
analysis getting done. Otherwise you have to basically code multiple 
paths to setup for the different functions as they now stand.

Part of the motivation for this was writing the driving directions code 
so it had mimimal impact on the code when changing the analysis method 
between dijkstra, astar and shootingstar.

-Steve

> Dan
>
>
>
> --- On Fri, 1/28/11, Stephen Woodbridge<woodbri at swoodbridge.com>  wrote:
>
>> From: Stephen Woodbridge<woodbri at swoodbridge.com>
>> Subject: Re: [pgrouting-users] Table location
>> To: pgrouting-users at lists.osgeo.org
>> Received: Friday, January 28, 2011, 10:00 AM
>> I cloned vertex assignment code to
>> change it for zlevels and it was
>> trivial to make it run in another schema. I think all you
>> need to do is:
>>
>> 1. remove all the explicit references to "public." from the
>> stored
>> procedure and reload it in you "data." schema
>>
>> 2. then make sure you set the default db search path like:
>>
>> alter database mydb set search_path to data, public;
>>
>> And everything is good.
>>
>> -Steve
>>
>> On 1/28/2011 1:39 AM, Dan Putler wrote:
>>> Given your comment on vertex assignments needing to be
>> done in the
>>> public schema, I'm now not sure. I may have had a
>> problem with the
>>> vertex assignments, looked through that code and
>> discovered that it
>>> didn't handle anything other than the public schema
>> well, and just put
>>> everything in public after that. I did this in July,
>> so things are on
>>> the hazy side. What I was working on isn't part of a
>> web application,
>>> and I am behind a firewall, so I was safe in keeping
>> everything in the
>>> public schema.
>>>
>>> Dan
>>>
>>>
>>> --- On *Thu, 1/27/11, Henrik Berggren /<henke.berggren at gmail.com>/*
>> wrote:
>>>
>>>
>>>       From: Henrik Berggren<henke.berggren at gmail.com>
>>>       Subject: Re: [pgrouting-users]
>> Table location
>>>       To: "pgRouting users mailing
>> list"<pgrouting-users at lists.osgeo.org>
>>>       Received: Thursday, January
>> 27, 2011, 10:26 AM
>>>
>>>       Are you sure about that the
>> data needs to be in the public schema
>>>       for shooting_star to work
>> properly?
>>>
>>>       /Henrik
>>>
>>>       On 01/27/2011 07:06 PM, Dan
>> Putler wrote:
>>>>       I also found that I could
>> only use pgrouting with a data table
>>>>       that are in the public
>> schema. My memory is that in some of the
>>>>       functions (I know this is
>> true for the shooting star algorithm),
>>>>       the public schema is "hard
>> wired" within the code.
>>>>
>>>>       Dan
>>>>
>>>>       --- On *Thu, 1/27/11,
>> Daniel Kastl /<daniel at georepublic.de>
>>>>       </mc/compose?to=daniel at georepublic.de>/*
>> wrote:
>>>>
>>>>
>>>>           From: Daniel
>> Kastl<daniel at georepublic.de>
>>>>
>>     </mc/compose?to=daniel at georepublic.de>
>>>>           Subject: Re:
>> [pgrouting-users] Table location
>>>>           To:
>> "pgRouting users mailing list"
>>>>           <pgrouting-users at lists.osgeo.org>
>>>>
>>     </mc/compose?to=pgrouting-users at lists.osgeo.org>
>>>>           Received:
>> Thursday, January 27, 2011, 8:18 AM
>>>>
>>>>           Good
>> question, Ricardo!
>>>>           And thank
>> you for sharing your experience, Henrik.
>>>>
>>>>           I must admit
>> I haven't tried it, and probably the majority of
>>>>           users always
>> works in public schema.
>>>>           I added a
>> ticket not to forget about this, because I think it
>>>>           would be
>> nice to support the schema in all functions:
>>>>           https://github.com/pgRouting/pgrouting/issues/issue/24
>>>>
>>>>           Daniel
>>>>
>>>>
>>>>           2011/1/28
>> Henrik Berggren<henke.berggren at gmail.com>
>>>>
>>>>
>>     You can have it in other schemes but you
>> need to run the
>>>>
>>     assign_vertex_id in the public scheme,
>> that is my experience.
>>>>
>>>>
>>     /H
>>>>
>>>>
>>>>
>>>>
>>     On 01/25/2011 10:42 PM, Ricardo Bayley
>> wrote:
>>>>>
>>     Hi everyone,
>>>>>
>>>>>
>>     I am wondering, does pgrouting require to
>> have tables on
>>>>>
>>     the public schema ? or could they be on
>> any schema ?
>>>>>
>>>>>
>>>>>
>>     Thanks,
>>>>>
>>>>>
>>>>>
>>     Ricardo
>>>>>
>>>>>
>>     _______________________________________________
>>>>>
>>     Pgrouting-users mailing list
>>>>>
>>     Pgrouting-users at lists.osgeo.org
>>>>>
>>     http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>>>
>>>>
>>     _______________________________________________
>>>>
>>     Pgrouting-users mailing list
>>>>
>>     Pgrouting-users at lists.osgeo.org
>>>>
>>     http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>>>
>>>>
>>>>
>>>>
>>>>           --
>>>>           Georepublic
>> UG&  Georepublic Japan
>>>>           eMail: daniel.kastl at georepublic.de
>>>>           Web: http://georepublic.de<http://georepublic.de/>
>>>>
>>>>           -----Inline
>> Attachment Follows-----
>>>>
>>>>
>>     _______________________________________________
>>>>
>>     Pgrouting-users mailing list
>>>>           Pgrouting-users at lists.osgeo.org
>>>>           http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>>>
>>>>
>>>>
>>>>
>>     _______________________________________________
>>>>       Pgrouting-users mailing
>> list
>>>>       Pgrouting-users at lists.osgeo.org
>> </mc/compose?to=Pgrouting-users at lists.osgeo.org>
>>>>       http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>>
>>>       -----Inline Attachment
>> Follows-----
>>>
>>>
>>     _______________________________________________
>>>       Pgrouting-users mailing list
>>>       Pgrouting-users at lists.osgeo.org
>>>       </mc/compose?to=Pgrouting-users at lists.osgeo.org>
>>>       http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pgrouting-users mailing list
>>> Pgrouting-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>
>> _______________________________________________
>> Pgrouting-users mailing list
>> Pgrouting-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-users
>>
>
>
> _______________________________________________
> Pgrouting-users mailing list
> Pgrouting-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-users



More information about the Pgrouting-users mailing list