[pgrouting-users] routing_core_smart problem

Worth_Lutz · December 2, 2011, 7:26pm

Hi all,

I have found what appears to be a problem in one of the routing_core_smart functions.

In the function locate_point_as_geometry there are two lines which call the function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument for the srid. This produces a geometry with a “-1” for the srid.

When I use shootingstar_smart in my script, MapServer fails on trying to work with two geometries with different srids.

Adding the second argument to the geometryfromtext function fixed this problem. The only geometry with the “-1” srid was the one created by these function calls.

I hope this helps someone.

Worth Lutz

dkastl · December 3, 2011, 2:57am

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket: https://github.com/pgRouting/pgrouting-contrib/issues/3

So you’re talking about the following two lines?

Line 191 https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191
Line 205 https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205
Best regards,

Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com> wrote:

Hi all,

I have found what appears to be a problem in one of the routing_core_smart functions.

In the function locate_point_as_geometry there are two lines which call the function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument for the srid. This produces a geometry with a “-1” for the srid.

When I use shootingstar_smart in my script, MapServer fails on trying to work with two geometries with different srids.

Adding the second argument to the geometryfromtext function fixed this problem. The only geometry with the “-1” srid was the one created by these function calls.

I hope this helps someone.

Worth Lutz

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Worth_Lutz · December 3, 2011, 1:55pm

Daniel,

Yes, those lines are correct.

Without the second argument to the function call you get an unknown (-1)
srid.

This route segment is then returned in the routing result along with the
others with the correct srid.

Worth

_____

From: pgrouting-users-bounces@lists.osgeo.org
[mailto:pgrouting-users-bounces@lists.osgeo.org] On Behalf Of Daniel Kastl
Sent: Friday, December 02, 2011 9:58 PM
To: pgRouting users mailing list
Subject: Re: [pgrouting-users] routing_core_smart problem

Hi Lutz,

Thank you very much for sharing this information!

I have also created this ticket:
https://github.com/pgRouting/pgrouting-contrib/issues/3

So you're talking about the following two lines?

* Line 191
https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_c
ore_smart.sql#L191
* Line 205
https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_c
ore_smart.sql#L205

Best regards,

Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com> wrote:

Hi all,

I have found what appears to be a problem in one of the routing_core_smart
functions.

In the function locate_point_as_geometry there are two lines which call the
function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument for the
srid. This produces a geometry with a "-1" for the srid.

When I use shootingstar_smart in my script, MapServer fails on trying to
work with two geometries with different srids.

Adding the second argument to the geometryfromtext function fixed this
problem. The only geometry with the "-1" srid was the one created by these
function calls.

I hope this helps someone.

Worth Lutz

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: <mailto:daniel.kastl@georepublic.de> daniel.kastl@georepublic.de
Web: <http://georepublic.de/> http://georepublic.de

_____

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1873 / Virus Database: 2102/4652 - Release Date: 12/02/11

Stephen_Woodbridge1 · December 4, 2011, 3:28pm

Hi Daniel,

Who wrote the routing_core_smart.sql functions?
Is there any documentation of them? It would be nice if we had:
1. description of the major public entry points and what the arguments should be.
2. comments in the code that explain what the overview strategy is and/or a high level pseudocode of how it executes

Thanks,
-Steve

On 12/2/2011 9:57 PM, Daniel Kastl wrote:

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket:
https://github.com/pgRouting/pgrouting-contrib/issues/3

So you're talking about the following two lines?

  * Line 191
    https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191
  * Line 205
    https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205

Best regards,
Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com
<mailto:wal3@mindspring.com>> wrote:

    Hi all,

    I have found what appears to be a problem in one of the
    routing_core_smart functions.

    In the function locate_point_as_geometry there are two lines which
    call the function geometryfromtext.

    These functions are called when line_substring returns a point.

    In the geometryfromtext function calls, there is no second argument
    for the srid. This produces a geometry with a “-1” for the srid.

    When I use shootingstar_smart in my script, MapServer fails on
    trying to work with two geometries with different srids.

    Adding the second argument to the geometryfromtext function fixed
    this problem. The only geometry with the “-1” srid was the one
    created by these function calls.

    I hope this helps someone.

    Worth Lutz

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

dkastl · December 4, 2011, 3:39pm

On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi Daniel,

Who wrote the routing_core_smart.sql functions?

Anton

Is there any documentation of them? It would be nice if we had:

Right … would be nice to have
I actually just decided to publish the wrapper, because there were several questions in the past how the pgRouting demo could start the route from/to the point you clicked.

description of the major public entry points and what the arguments should be.

It even needs an extra table “network_statistics” to work.
But on the other hand it was supposed to be an example of writing a more complex wrapper function. It’s not really a generic function and may not work with any type of data.
There are probably several possibilities to improve the functions.

Daniel

comments in the code that explain what the overview strategy is and/or a high level pseudocode of how it executes

Thanks,
-Steve

On 12/2/2011 9:57 PM, Daniel Kastl wrote:

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket:
https://github.com/pgRouting/pgrouting-contrib/issues/3

So you’re talking about the following two lines?

Line 191
https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191

Line 205

https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205

Best regards,
Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com

mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)> wrote:

Hi all,

I have found what appears to be a problem in one of the
routing_core_smart functions.

In the function locate_point_as_geometry there are two lines which
call the function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument
for the srid. This produces a geometry with a “-1” for the srid.

When I use shootingstar_smart in my script, MapServer fails on
trying to work with two geometries with different srids.

Adding the second argument to the geometryfromtext function fixed
this problem. The only geometry with the “-1” srid was the one
created by these function calls.

I hope this helps someone.

Worth Lutz

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan

eMail: daniel.kastl@georepublic.de mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)
Web: http://georepublic.de <http://georepublic.de/>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Worth_Lutz · December 4, 2011, 11:35pm

As Daniel noted, the function will not work with all types of data.

I cannot remember now but I had to change something in it to make it work
with my data. I could diff against the original and tell you what if anyone
is interested.

It is a great example though. It taught me how to use pl/pgsql to solve
problems I was having.

Worth Lutz

_____

From: pgrouting-users-bounces@lists.osgeo.org
[mailto:pgrouting-users-bounces@lists.osgeo.org] On Behalf Of Daniel Kastl
Sent: Sunday, December 04, 2011 10:39 AM
To: pgRouting users mailing list
Subject: Re: [pgrouting-users] routing_core_smart problem

On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

Hi Daniel,

Who wrote the routing_core_smart.sql functions?

Anton

Is there any documentation of them? It would be nice if we had:

Right ... would be nice to have

I actually just decided to publish the wrapper, because there were several
questions in the past how the pgRouting demo could start the route from/to
the point you clicked.

1. description of the major public entry points and what the arguments
should be.

It even needs an extra table "network_statistics" to work.

But on the other hand it was supposed to be an example of writing a more
complex wrapper function. It's not really a generic function and may not
work with any type of data.

There are probably several possibilities to improve the functions.

Daniel

2. comments in the code that explain what the overview strategy is and/or a
high level pseudocode of how it executes

Thanks,
-Steve

On 12/2/2011 9:57 PM, Daniel Kastl wrote:

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket:
https://github.com/pgRouting/pgrouting-contrib/issues/3

So you're talking about the following two lines?

* Line 191

https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_c
ore_smart.sql#L191
* Line 205

https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_c
ore_smart.sql#L205

Best regards,
Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com

<mailto:wal3@mindspring.com>> wrote:

Hi all,

I have found what appears to be a problem in one of the
routing_core_smart functions.

In the function locate_point_as_geometry there are two lines which
call the function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument
for the srid. This produces a geometry with a "-1" for the srid.

When I use shootingstar_smart in my script, MapServer fails on
trying to work with two geometries with different srids.

   Adding the second argument to the geometryfromtext function fixed
   this problem. The only geometry with the "-1" srid was the one
   created by these function calls.

I hope this helps someone.

Worth Lutz

_______________________________________________
Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org <mailto:Pgrouting-users@lists.osgeo.org>

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan

eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: <mailto:daniel.kastl@georepublic.de> daniel.kastl@georepublic.de
Web: <http://georepublic.de/> http://georepublic.de

_____

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date: 12/04/11

Stephen_Woodbridge1 · December 5, 2011, 12:39am

Hi Worth and all,

Thanks for the offer but no need for that now.
My main concern was that looking at it, it does not seem that we want to make it a part of the core functionality for a few reasons:

o it is not documented
o as pointed out it is not generalized and has some assumptions
o a lot of the code could be simplified and made more efficient nor is it the best example, although I'm sure it did the job that was needed at the time
o our experience has been that wrappers that get release as examples tend to get used as the "main" API to pgrouting and therefore need to be clear, easy to follow and well documented.

Having said that, we need some nice wrappers. I have written my own wrappers, but alas they also suffer from many of the same ills, I mentioned because I wrote them for my own use/reuse and not for the general public. If I can find some time it is on my list of things to do for pgrouting.

Thanks,
-Steve

On 12/4/2011 6:35 PM, Worth Lutz wrote:

As Daniel noted, the function will not work with all types of data.

I cannot remember now but I had to change something in it to make it
work with my data. I could diff against the original and tell you what
if anyone is interested.

It is a great example though. It taught me how to use pl/pgsql to solve
problems I was having.

Worth Lutz

*From: * pgrouting-users-bounces@lists.osgeo.org
[mailto:pgrouting-users-bounces@lists.osgeo.org] *On Behalf Of *Daniel Kastl
*Sent:* Sunday, December 04, 2011 10:39 AM
*To:* pgRouting users mailing list
*Subject:* Re: [pgrouting-users] routing_core_smart problem

On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

Hi Daniel,

Who wrote the routing_core_smart.sql functions?

Anton

    Is there any documentation of them? It would be nice if we had:

Right ... would be nice to have

I actually just decided to publish the wrapper, because there were
several questions in the past how the pgRouting demo could start the
route from/to the point you clicked.

    1. description of the major public entry points and what the
    arguments should be.

It even needs an extra table "network_statistics" to work.

But on the other hand it was supposed to be an example of writing a more
complex wrapper function. It's not really a generic function and may not
work with any type of data.

There are probably several possibilities to improve the functions.

Daniel

    2. comments in the code that explain what the overview strategy is
    and/or a high level pseudocode of how it executes

    Thanks,
    -Steve

    On 12/2/2011 9:57 PM, Daniel Kastl wrote:

        Hi Lutz,

        Thank you very much for sharing this information!
        I have also created this ticket:
        https://github.com/pgRouting/pgrouting-contrib/issues/3

        So you're talking about the following two lines?

        * Line 191
        https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191
        * Line 205

        https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205

        Best regards,
        Daniel

        On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com
        <mailto:wal3@mindspring.com>

        <mailto:wal3@mindspring.com>> wrote:

        Hi all,

        I have found what appears to be a problem in one of the
        routing_core_smart functions.

        In the function locate_point_as_geometry there are two lines which
        call the function geometryfromtext.

        These functions are called when line_substring returns a point.

        In the geometryfromtext function calls, there is no second argument
        for the srid. This produces a geometry with a “-1” for the srid.

        When I use shootingstar_smart in my script, MapServer fails on
        trying to work with two geometries with different srids.

        Adding the second argument to the geometryfromtext function fixed
        this problem. The only geometry with the “-1” srid was the one
        created by these function calls.

        I hope this helps someone.

        Worth Lutz

        _______________________________________________
        Pgrouting-users mailing list

        Pgrouting-users@lists.osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>
        <mailto:Pgrouting-users@lists.osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>>

        http://lists.osgeo.org/mailman/listinfo/pgrouting-users

        --
        Georepublic UG & Georepublic Japan

        eMail: daniel.kastl@georepublic.de
        <mailto:daniel.kastl@georepublic.de>
        <mailto:daniel.kastl@georepublic.de
        <mailto:daniel.kastl@georepublic.de>>
        Web: http://georepublic.de/>

        _______________________________________________
        Pgrouting-users mailing list
        Pgrouting-users@lists.osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>
        http://lists.osgeo.org/mailman/listinfo/pgrouting-users

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date: 12/04/11

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

dkastl · December 5, 2011, 1:13am

Hi Steve,

I fully agree. Well, the idea of the pgrouting-contrib repository is to collect stuff like that: wrapper examples, scripts like the one to create a pgRouting database template, etc…
The purpose of this repository is not to provide widely tested and perfect wrappers. But as Worth said, it can be of great help to have some examples if you want to write your first own wrapper function. And it’s not a good idea to put too many wrapper functions into core library. There are already too many.

So I think it’s better to publish “unfinished” and custom code samples, because that still helps users more than no examples at all, right? In the worst case it’s just there and can be taken as a reference to answer questions in the mailing list, in the best case someone contributes feedback or even improvements.

Unfortunately it pgrouting-contrib has never grown beyond the one wrapper and a few other things. Probably it wasn’t explained clear enough that everyone is welcome to add their examples there. Or it’s too difficult to contribute.

Daniel

On Mon, Dec 5, 2011 at 9:39 AM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Hi Worth and all,

Thanks for the offer but no need for that now.
My main concern was that looking at it, it does not seem that we want to make it a part of the core functionality for a few reasons:

o it is not documented
o as pointed out it is not generalized and has some assumptions
o a lot of the code could be simplified and made more efficient nor is it the best example, although I’m sure it did the job that was needed at the time
o our experience has been that wrappers that get release as examples tend to get used as the “main” API to pgrouting and therefore need to be clear, easy to follow and well documented.

Having said that, we need some nice wrappers. I have written my own wrappers, but alas they also suffer from many of the same ills, I mentioned because I wrote them for my own use/reuse and not for the general public. If I can find some time it is on my list of things to do for pgrouting.

Thanks,
-Steve

On 12/4/2011 6:35 PM, Worth Lutz wrote:

As Daniel noted, the function will not work with all types of data.

I cannot remember now but I had to change something in it to make it
work with my data. I could diff against the original and tell you what
if anyone is interested.

It is a great example though. It taught me how to use pl/pgsql to solve
problems I was having.

Worth Lutz

*From: * pgrouting-users-bounces@lists.osgeo.org
[mailto:pgrouting-users-bounces@lists.osgeo.org] *On Behalf Of *Daniel Kastl
Sent: Sunday, December 04, 2011 10:39 AM
To: pgRouting users mailing list
Subject: Re: [pgrouting-users] routing_core_smart problem

On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge

<woodbri@swoodbridge.com mailto:[woodbri@swoodbridge.com](mailto:woodbri@swoodbridge.com)> wrote:

Hi Daniel,

Who wrote the routing_core_smart.sql functions?

Anton

Is there any documentation of them? It would be nice if we had:

Right … would be nice to have

I actually just decided to publish the wrapper, because there were
several questions in the past how the pgRouting demo could start the
route from/to the point you clicked.

description of the major public entry points and what the
arguments should be.

It even needs an extra table “network_statistics” to work.

But on the other hand it was supposed to be an example of writing a more
complex wrapper function. It’s not really a generic function and may not
work with any type of data.

There are probably several possibilities to improve the functions.

Daniel

comments in the code that explain what the overview strategy is
and/or a high level pseudocode of how it executes

Thanks,
-Steve

On 12/2/2011 9:57 PM, Daniel Kastl wrote:

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket:
https://github.com/pgRouting/pgrouting-contrib/issues/3

So you’re talking about the following two lines?

Line 191
https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191

Line 205

https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205

Best regards,
Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz <wal3@mindspring.com
mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)

<mailto:wal3@mindspring.com mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)>> wrote:

Hi all,

I have found what appears to be a problem in one of the
routing_core_smart functions.

In the function locate_point_as_geometry there are two lines which
call the function geometryfromtext.

These functions are called when line_substring returns a point.

In the geometryfromtext function calls, there is no second argument
for the srid. This produces a geometry with a “-1” for the srid.

When I use shootingstar_smart in my script, MapServer fails on
trying to work with two geometries with different srids.

Adding the second argument to the geometryfromtext function fixed
this problem. The only geometry with the “-1” srid was the one
created by these function calls.

I hope this helps someone.

Worth Lutz

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)

<mailto:Pgrouting-users@lists.osgeo.org

mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)>

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan

eMail: daniel.kastl@georepublic.de
mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)

<mailto:daniel.kastl@georepublic.de

mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)>
Web: http://georepublic.de <http://georepublic.de/>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org

mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)

http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo.org mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)
Web: http://georepublic.de <http://georepublic.de/>

No virus found in this message.

Checked by AVG - www.avg.com <http://www.avg.com>

Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date: 12/04/11

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Stephen_Woodbridge1 · December 5, 2011, 1:40am

Daniel,

Ok, this makes some sense. I would like us to try and set some minimum requirements for the contrib submissions. Like when a file(s) is contributed it gets a named like:
   <whatever>-cod.sql - example code
   <whatever>-doc.txt - file with some minimum doc in it
   <whatever>-dat.sql - sample data in pg_dump -fP format compressed with gzip

For example of <whatever>-doc.txt:

Author
- name
- email
- date
- pgRouting version
- copyright
Overview
- what does this file do or show from an example point of view
Assumptions
- ....
How do I use it
- how to load and prep <whatever>-dat.sql.gz
- list of sql statements to run the example code and the expected results.

We can relax these on a case by case basis after the PSC has had a chance to review potential submissions. This is less to raise a barrier and more to set some quality standards for pgRouting. People can always post code in blogs and private git repositories, etc without meeting these standards. Also if pgRouting changes in some way and the examples not longer work and no one is interested in updating them, then they should be removed.

My 2 cents,
-Steve

On 12/4/2011 8:13 PM, Daniel Kastl wrote:

Hi Steve,

I fully agree. Well, the idea of the pgrouting-contrib repository is to
collect stuff like that: wrapper examples, scripts like the one to
create a pgRouting database template, etc..
The purpose of this repository is not to provide widely tested and
perfect wrappers. But as Worth said, it can be of great help to have
some examples if you want to write your first own wrapper function. And
it's not a good idea to put too many wrapper functions into core
library. There are already too many.

So I think it's better to publish "unfinished" and custom code samples,
because that still helps users more than no examples at all, right?
In the worst case it's just there and can be taken as a reference to
answer questions in the mailing list, in the best case someone
contributes feedback or even improvements.

Unfortunately it pgrouting-contrib has never grown beyond the one
wrapper and a few other things. Probably it wasn't explained clear
enough that everyone is welcome to add their examples there. Or it's too
difficult to contribute.

Daniel

On Mon, Dec 5, 2011 at 9:39 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    Hi Worth and all,

    Thanks for the offer but no need for that now.
    My main concern was that looking at it, it does not seem that we
    want to make it a part of the core functionality for a few reasons:

    o it is not documented
    o as pointed out it is not generalized and has some assumptions
    o a lot of the code could be simplified and made more efficient nor
    is it the best example, although I'm sure it did the job that was
    needed at the time
    o our experience has been that wrappers that get release as examples
    tend to get used as the "main" API to pgrouting and therefore need
    to be clear, easy to follow and well documented.

    Having said that, we need some nice wrappers. I have written my own
    wrappers, but alas they also suffer from many of the same ills, I
    mentioned because I wrote them for my own use/reuse and not for the
    general public. If I can find some time it is on my list of things
    to do for pgrouting.

    Thanks,
      -Steve

    On 12/4/2011 6:35 PM, Worth Lutz wrote:

        As Daniel noted, the function will not work with all types of data.

        I cannot remember now but I had to change something in it to make it
        work with my data. I could diff against the original and tell
        you what
        if anyone is interested.

        It is a great example though. It taught me how to use pl/pgsql
        to solve
        problems I was having.

        Worth Lutz

        *From: * pgrouting-users-bounces@lists. osgeo.org
        <mailto:pgrouting-users-bounces@lists.osgeo.org>
        [mailto:pgrouting-users- bounces@lists.osgeo.org
        <mailto:pgrouting-users-bounces@lists.osgeo.org>] *On Behalf Of
        *Daniel Kastl
        *Sent:* Sunday, December 04, 2011 10:39 AM
        *To:* pgRouting users mailing list
        *Subject:* Re: [pgrouting-users] routing_core_smart problem

        On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge
        <woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>
        <mailto:woodbri@swoodbridge. com
        <mailto:woodbri@swoodbridge.com>>> wrote:

        Hi Daniel,

        Who wrote the routing_core_smart.sql functions?

        Anton

            Is there any documentation of them? It would be nice if we had:

        Right ... would be nice to have

        I actually just decided to publish the wrapper, because there were
        several questions in the past how the pgRouting demo could start the
        route from/to the point you clicked.

            1. description of the major public entry points and what the
            arguments should be.

        It even needs an extra table "network_statistics" to work.

        But on the other hand it was supposed to be an example of
        writing a more
        complex wrapper function. It's not really a generic function and
        may not
        work with any type of data.

        There are probably several possibilities to improve the functions.

        Daniel

            2. comments in the code that explain what the overview
        strategy is
            and/or a high level pseudocode of how it executes

            Thanks,
            -Steve

            On 12/2/2011 9:57 PM, Daniel Kastl wrote:

                Hi Lutz,

                Thank you very much for sharing this information!
                I have also created this ticket:
        https://github.com/pgRouting/ pgrouting-contrib/issues/3
        <https://github.com/pgRouting/pgrouting-contrib/issues/3>

                So you're talking about the following two lines?

                * Line 191
        https://github.com/pgRouting/ pgrouting-contrib/blob/master/
        wrapper/routing_core_smart. sql#L191
        <https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191>
                * Line 205

        https://github.com/pgRouting/ pgrouting-contrib/blob/master/
        wrapper/routing_core_smart. sql#L205
        <https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205>

                Best regards,
                Daniel

                On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz
        <wal3@mindspring.com <mailto:wal3@mindspring.com>
        <mailto:wal3@mindspring.com>

        <mailto:wal3@mindspring.com
        <mailto:wal3@mindspring.com>>> wrote:

                Hi all,

                I have found what appears to be a problem in one of the
                routing_core_smart functions.

                In the function locate_point_as_geometry there are two
        lines which
                call the function geometryfromtext.

                These functions are called when line_substring returns a
        point.

                In the geometryfromtext function calls, there is no
        second argument
                for the srid. This produces a geometry with a “-1” for
        the srid.

                When I use shootingstar_smart in my script, MapServer
        fails on
                trying to work with two geometries with different srids.

                Adding the second argument to the geometryfromtext
        function fixed
                this problem. The only geometry with the “-1” srid was
        the one
                created by these function calls.

                I hope this helps someone.

                Worth Lutz

                ______________________________ _________________
                Pgrouting-users mailing list

        Pgrouting-users@lists.osgeo. org
        <mailto:Pgrouting-users@lists.osgeo.org>
        <mailto:Pgrouting-users@lists. osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>>
        <mailto:Pgrouting-users@lists. osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>

        <mailto:Pgrouting-users@lists. osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>>>

        http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
        <http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

                --
                Georepublic UG & Georepublic Japan

                eMail: daniel.kastl@georepublic.de
        <mailto:daniel.kastl@georepublic.de>
        <mailto:daniel.kastl@ georepublic.de
        <mailto:daniel.kastl@georepublic.de>>
        <mailto:daniel.kastl@ georepublic.de
        <mailto:daniel.kastl@georepublic.de>

        <mailto:daniel.kastl@ georepublic.de
        <mailto:daniel.kastl@georepublic.de>>>
                Web: http://georepublic.de/>

                ______________________________ _________________
                Pgrouting-users mailing list
        Pgrouting-users@lists.osgeo. org
        <mailto:Pgrouting-users@lists.osgeo.org>
        <mailto:Pgrouting-users@lists. osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>>

        http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
        <http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

            ______________________________ _________________
            Pgrouting-users mailing list
        Pgrouting-users@lists.osgeo. org
        <mailto:Pgrouting-users@lists.osgeo.org>
        <mailto:Pgrouting-users@lists. osgeo.org
        <mailto:Pgrouting-users@lists.osgeo.org>>
        http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
        <http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

        --
        Georepublic UG & Georepublic Japan
        eMail: daniel.kastl@georepublic.de
        <mailto:daniel.kastl@georepublic.de> <mailto:daniel.kastl@
        georepublic.de <mailto:daniel.kastl@georepublic.de>>
        Web: http://georepublic.de/>

        No virus found in this message.
        Checked by AVG - www.avg.com <http://www.avg.com>
        <http://www.avg.com>

        Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date:
        12/04/11

        ______________________________ _________________
        Pgrouting-users mailing list
        Pgrouting-users@lists.osgeo. org
        <mailto:Pgrouting-users@lists.osgeo.org>
        http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
        <http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

    ______________________________ _________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo. org
    <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
    <http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

dkastl · December 5, 2011, 1:56am

Hi Steve,

It’s a good idea.
Though I assume we won’t get overloaded with submissions

I think we could add your submission guidelines as a README in the repository root: https://github.com/pgRouting/pgrouting-contrib
It’s content then shows up automatically beneath the directories.

I guess the amount of files will vary depending on the type of document. Some contributions may not need sample data (for example the template script), some might better have an own directory. So I would make it more pragmatic and see the guidelines as a recommendation. Though the result should be usable and understandable and it should be documented, who wrote it and under which license … so not like the files I added

Daniel

On Mon, Dec 5, 2011 at 10:40 AM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:

Daniel,

Ok, this makes some sense. I would like us to try and set some minimum requirements for the contrib submissions. Like when a file(s) is contributed it gets a named like:
-cod.sql - example code
-doc.txt - file with some minimum doc in it
-dat.sql - sample data in pg_dump -fP format compressed with gzip

For example of -doc.txt:

Author

name

email

date

pgRouting version

copyright
Overview

what does this file do or show from an example point of view
Assumptions

…
How do I use it

how to load and prep -dat.sql.gz

list of sql statements to run the example code and the expected results.

We can relax these on a case by case basis after the PSC has had a chance to review potential submissions. This is less to raise a barrier and more to set some quality standards for pgRouting. People can always post code in blogs and private git repositories, etc without meeting these standards. Also if pgRouting changes in some way and the examples not longer work and no one is interested in updating them, then they should be removed.

My 2 cents,
-Steve

On 12/4/2011 8:13 PM, Daniel Kastl wrote:

Hi Steve,

I fully agree. Well, the idea of the pgrouting-contrib repository is to
collect stuff like that: wrapper examples, scripts like the one to
create a pgRouting database template, etc…
The purpose of this repository is not to provide widely tested and
perfect wrappers. But as Worth said, it can be of great help to have
some examples if you want to write your first own wrapper function. And
it’s not a good idea to put too many wrapper functions into core
library. There are already too many.

So I think it’s better to publish “unfinished” and custom code samples,
because that still helps users more than no examples at all, right?
In the worst case it’s just there and can be taken as a reference to
answer questions in the mailing list, in the best case someone
contributes feedback or even improvements.

Unfortunately it pgrouting-contrib has never grown beyond the one
wrapper and a few other things. Probably it wasn’t explained clear
enough that everyone is welcome to add their examples there. Or it’s too
difficult to contribute.

Daniel

On Mon, Dec 5, 2011 at 9:39 AM, Stephen Woodbridge

<woodbri@swoodbridge.com mailto:[woodbri@swoodbridge.com](mailto:woodbri@swoodbridge.com)> wrote:

Hi Worth and all,

Thanks for the offer but no need for that now.
My main concern was that looking at it, it does not seem that we
want to make it a part of the core functionality for a few reasons:

o it is not documented
o as pointed out it is not generalized and has some assumptions
o a lot of the code could be simplified and made more efficient nor
is it the best example, although I’m sure it did the job that was
needed at the time
o our experience has been that wrappers that get release as examples
tend to get used as the “main” API to pgrouting and therefore need
to be clear, easy to follow and well documented.

Having said that, we need some nice wrappers. I have written my own
wrappers, but alas they also suffer from many of the same ills, I
mentioned because I wrote them for my own use/reuse and not for the
general public. If I can find some time it is on my list of things
to do for pgrouting.

Thanks,
-Steve

On 12/4/2011 6:35 PM, Worth Lutz wrote:

As Daniel noted, the function will not work with all types of data.

I cannot remember now but I had to change something in it to make it
work with my data. I could diff against the original and tell
you what
if anyone is interested.

It is a great example though. It taught me how to use pl/pgsql
to solve
problems I was having.

Worth Lutz

*From: * pgrouting-users-bounces@lists. osgeo.org

mailto:[pgrouting-users-bounces@lists.osgeo.org](mailto:pgrouting-users-bounces@lists.osgeo.org)
[mailto:pgrouting-users- bounces@lists.osgeo.org

mailto:[pgrouting-users-bounces@lists.osgeo.org](mailto:pgrouting-users-bounces@lists.osgeo.org)] *On Behalf Of
*Daniel Kastl
Sent: Sunday, December 04, 2011 10:39 AM
To: pgRouting users mailing list
Subject: Re: [pgrouting-users] routing_core_smart problem

On Mon, Dec 5, 2011 at 12:28 AM, Stephen Woodbridge
<woodbri@swoodbridge.com mailto:[woodbri@swoodbridge.com](mailto:woodbri@swoodbridge.com)

<mailto:woodbri@swoodbridge. com

mailto:[woodbri@swoodbridge.com](mailto:woodbri@swoodbridge.com)>> wrote:

Hi Daniel,

Who wrote the routing_core_smart.sql functions?

Anton

Is there any documentation of them? It would be nice if we had:

Right … would be nice to have

I actually just decided to publish the wrapper, because there were
several questions in the past how the pgRouting demo could start the
route from/to the point you clicked.

description of the major public entry points and what the
arguments should be.

It even needs an extra table “network_statistics” to work.

But on the other hand it was supposed to be an example of
writing a more
complex wrapper function. It’s not really a generic function and
may not
work with any type of data.

There are probably several possibilities to improve the functions.

Daniel

comments in the code that explain what the overview
strategy is
and/or a high level pseudocode of how it executes

Thanks,
-Steve

On 12/2/2011 9:57 PM, Daniel Kastl wrote:

Hi Lutz,

Thank you very much for sharing this information!
I have also created this ticket:
https://github.com/pgRouting/ pgrouting-contrib/issues/3
<https://github.com/pgRouting/pgrouting-contrib/issues/3>

So you’re talking about the following two lines?

Line 191
https://github.com/pgRouting/ pgrouting-contrib/blob/master/
wrapper/routing_core_smart. sql#L191
<https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L191>

Line 205

https://github.com/pgRouting/ pgrouting-contrib/blob/master/
wrapper/routing_core_smart. sql#L205
<https://github.com/pgRouting/pgrouting-contrib/blob/master/wrapper/routing_core_smart.sql#L205>

Best regards,
Daniel

On Sat, Dec 3, 2011 at 4:26 AM, Worth Lutz
<wal3@mindspring.com mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)
<mailto:wal3@mindspring.com mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)>

<mailto:wal3@mindspring.com mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)
<mailto:wal3@mindspring.com mailto:[wal3@mindspring.com](mailto:wal3@mindspring.com)>>> wrote:

Hi all,

I have found what appears to be a problem in one of the
routing_core_smart functions.

In the function locate_point_as_geometry there are two
lines which
call the function geometryfromtext.

These functions are called when line_substring returns a
point.

In the geometryfromtext function calls, there is no
second argument
for the srid. This produces a geometry with a “-1” for
the srid.

When I use shootingstar_smart in my script, MapServer
fails on
trying to work with two geometries with different srids.

Adding the second argument to the geometryfromtext
function fixed
this problem. The only geometry with the “-1” srid was
the one
created by these function calls.

I hope this helps someone.

Worth Lutz

Pgrouting-users mailing list

Pgrouting-users@lists.osgeo. org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
<mailto:Pgrouting-users@lists. osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)>

<mailto:Pgrouting-users@lists. osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)

<mailto:Pgrouting-users@lists. osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)>>

http://lists.osgeo.org/ mailman/listinfo/pgrouting- users

<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

–
Georepublic UG & Georepublic Japan

eMail: daniel.kastl@georepublic.de
mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)
<mailto:daniel.kastl@ georepublic.de
mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)>

<mailto:daniel.kastl@ georepublic.de
mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)

<mailto:daniel.kastl@ georepublic.de

mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)>>
Web: http://georepublic.de <http://georepublic.de/>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)

<mailto:Pgrouting-users@lists. osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)>

http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
<mailto:Pgrouting-users@lists. osgeo.org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)>
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users

<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de) <mailto:daniel.kastl@

georepublic.de mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)>
Web: http://georepublic.de <http://georepublic.de/>

No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
<http://www.avg.com>

Version: 2012.0.1873 / Virus Database: 2102/4656 - Release Date:
12/04/11

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org

mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users
<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo. org
mailto:[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
http://lists.osgeo.org/ mailman/listinfo/pgrouting- users

<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de mailto:[daniel.kastl@georepublic.de](mailto:daniel.kastl@georepublic.de)
Web: http://georepublic.de <http://georepublic.de/>

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de