[MAPSERVER-USERS] Any other Routing solution than pgRouting/Oracle NDM ?

[Gagan.Bansal at relianceada.com]

Hi Jon,

I am from Ritesh team. We are getting around 2 secs average response time 
for analysis in Oracle routing . I am in process of fine tuning like 
incorporating link level preference, fine tuning the partition size, 
connected components. I was also thinking of precaching the results(may be 
with xml) if it is available. Have you used any precaching also? 

Regards
Gagan



Jon Scarbrough <jscarbrough at where2getit.com> 
Sent by: mapserver-users-bounces at lists.osgeo.org
05/03/2008 03:24 AM

To
riteshambastha <ritesh.linux at gmail.com>
cc
mapserver-users at lists.osgeo.org
Subject
Re: [MAPSERVER-USERS] Any other Routing solution than pgRouting/Oracle NDM 
?






Ritesh,

I need to weigh in little bit since we are using the Oracle 
Geocoder/Routeserver in conjunction with the Navteq data set.  Our 
experience is that on a well tuned Oracle appserver/db cluster, an 
normal route will calculate in about .5 secs. But, there is a lot of 
tuning to get your java engine properly configured to deal with garbage 
collection and you must have enough memory to hold sufficient partitions 
in memory so you don't have to go back to disk.

We then take the Oracle route response and convert it to xml that is 
sent back to the browser and have Openlayers lay it on the map using 
SVG/VML. The biggest amount of time is spent parsing the XML and 
creating the SVG. There are a lot of moving parts and as Steve 
mentioned, you need to measure each part (route server, web server 
handling the conversion of route response to the browser, Openlayers 
layer manipulation).

In my experience, the Oracle router is not the bottleneck.

Thanks.

Jon Scarbrough
Where2GetIt.com


riteshambastha wrote:
> Thanks Steve, 
>
> I am pretty sure your words are making a mapserver enthusiast's life 
very
> easy. 
>
> For Route computation I am using a licensed version of Oracle Spatial 
DB.
> Now, as PostGIS is looking so promising in the market, I am also 
thinking to
> shift to PostGIS. 
>
> And after that, I will re-engineer my routing code using : 
> 
>> pgRouting
>> Ka-map xmlOverlay
>> 
>
> I guess I am going in the right direction.
>
> Regards,
> Ritesh Ambastha
>
>
>
> Stephen Woodbridge wrote:
> 
>> riteshambastha wrote:
>> 
>>> Thanks Steve,
>>>
>>> Route computation is taking an average time of 1.2 sec.
>>> Post this, showing route on the browser takes a lot of time. 
>>> I am not using kamap xml overlay and any lib of openlayers. 
>>>
>>> I am posting this route result xml into a db, and allowing a map file 
to
>>> read this db and show the route on map.
>>> I know this is not an efficient way to do the job. 
>>> 
>> I would start by adding some timing to a log file so you KNOW where 
your 
>> time is getting spent, then work on optimizing the larger times.
>>
>> I think this is the fastest way to go unless the route is relatively 
>> small in the number of nodes in the polyline. You should look at 
getting 
>> rid of the xml, in fact, why are you going to xml at all and then 
>> putting it back into the database. The data is being generate in the 
>> database then you extract it and format it into xml and then put the 
xml 
>> back into the database for mapserver to pick up. I think you should 
just 
>> put it into a table of routes with a unique sessionid+routeid key then 
>> pass the key to mapserver to use on selecting the right record.
>>
>> 
>>> I got to know that openlayers libs can help me to achieve the same. I
>>> want
>>> to know how in-efficient will be to use kamap xml overlay instead of 
any
>>> fn
>>> of openlayers.
>>> 
>> You can server the route as a wfs layer, but if it is complicated it 
>> might be too many points to handle quickly in the browser.
>>
>> -Steve
>>
>> 
>>> Regards,
>>> Ritesh Ambastha
>>>
>>> Stephen Woodbridge wrote:
>>> 
>>>> riteshambastha wrote:
>>>> 
>>>>> Dear friends, 
>>>>>
>>>>> I have seen routing based on postgis routing and oracle network data
>>>>> models.
>>>>> Even though, they serve the purpose very efficiently, they take some
>>>>> 1sec/2sec/3sec to display the routes. I checked them with OpenLayers
>>>>> and
>>>>> Ka-map. Still, I feel there must be a way to reduce this route 
display
>>>>> time.
>>>>> Is there any any other ways to show routing/directions over 
mapserver
>>>>> based
>>>>> maps? Any other data structure and programming in C/python can serve
>>>>> the
>>>>> purpose ?
>>>>> 
>>>> What is taking too long?
>>>> 1) is it the route computation
>>>> 2) transfering the route data to OpenLayers
>>>> 3) rendering the route data as a vector layer
>>>>
>>>> Have you considered writing some code on the server that generates an 

>>>> image file from the route data and returns a url for the image that 
can 
>>>> be then pinned to OpenLayers like a marker? You could do this by 
writing 
>>>> a wrapper in your favorite scripting language around the request to 
>>>> generate the route.
>>>>
>>>> -Steve W
>>>> _______________________________________________
>>>> mapserver-users mailing list
>>>> mapserver-users at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>>>
>>>>
>>>> 
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>>
>> 
>
> 
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users





The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20080507/c2dab3d4/attachment.html