{"id":7923,"date":"2019-01-28T03:54:54","date_gmt":"2019-01-28T02:54:54","guid":{"rendered":"http:\/\/www.sigterritoires.fr\/?p=7923"},"modified":"2022-02-17T09:36:09","modified_gmt":"2022-02-17T08:36:09","slug":"how-to-develop-an-application-with-pgrouting-in-windows-5-writing-a-wrapper","status":"publish","type":"post","link":"https:\/\/www.sigterritoires.fr\/index.php\/en\/how-to-develop-an-application-with-pgrouting-in-windows-5-writing-a-wrapper\/","title":{"rendered":"How to develop an application with pgrouting in Windows (5): writing a Wrapper"},"content":{"rendered":"\n

A wrapper is a PostgreSQL function that contains pgRouting and PostGIS<\/a> features easier to use than pgRouting and PostGIS functions straightaway.
The pgRouting native functions have been designed to be generic so they can be used in a wide range of applications . Although this offers flexibility, the disadvantage is that, most likely, you will have to reshape, temporarily, your own data structure before you applying pgRouting functions
Writing a wrapper function adapted to your data structure decreases the need to go through cumbersome SQL queries .
Another reason to use the wrapper function is to bypass the SQL injection attacks. Building a functional barrier between the  user\u2019s input and the function of native pgRouting native functions will allow you clear the user\u2019s input . <\/p>\n\n\n\n\n\n\n\n

PostgreSQL supports many programming languages for writing functions, but\nSQL and PL \/ pgSQL are the most common . We will discuss an example with PL \/ pgSQL\n. <\/p>\n\n\n\n

Until now, in our series of articles , we have restricted ourselves to\nthe network data level, but the final goal is to set up a route search web\napplication. In this case , the idea is to introduce to the user a map , and let\nhim define a starting and an ending point. Among the many possibilities , let’s\nremember the simplest: a click on the map to define the starting point and\nanother click to set the finish point . <\/p>\n\n\n\n

Our web page submits two pairs of xy coordinates and it is expected to retrieve\nthe advised itinerary connecting these two geographical points . <\/p>\n\n\n\n

If you have followed the series of articles , you can measure the\ndistance between what the web page results and the itinerary searches we have discussed,\nwhere we have to re-enter as parameters the starting and end nodes identifiers,\nas well as other settings according to the algorithm used . <\/p>\n\n\n\n

Let’s not forget that between our web page and our Postgresql \/ Postgis\ndatabase we will, also, have Geoserver . A possibility is to write a complex query\nin Geoserver , but we have a much simpler and more effective solution by using\na wrapper in PostgreSQL. <\/p>\n\n\n\n

This wrapper, which constitutes a new function that we will add in our Postgres database, will translate the xy transmitted by the web page in usable parameters by our route search algorithm, optimize its execution , and format the result for displaying in the web page. <\/p>\n\n\n\n

The code being used is a variation of an example found in different\nsites dealing with pgrouting under the name pgr_fromAtoB . <\/p>\n\n\n