data (#23) - Newbie questions (Navteq data) (#333) - Message List

Newbie questions (Navteq data)

Hi all

I'm new to all of this so please excuse any "stupid" questions.

Setup: Windows XP SP3 with postgresql 8.4.2 with postgis-pg84-1.4.1-1, pgRouting-1.03_pg-8.4.2 from binary Data: Navteq NAVSTREETS imported from shapefiles

I have a few things I'll be doing with our data but the primary task is to create a mapping from some foreign data links to ours. The links are described with a start and end point and a distance. So roughly speaking I'll find the nearest link to the start and end points and find the shortest path between them to figure out what links the link maps to. For the most part it will be only a few links (median appears to be .5 mile, max 10 miles on open roads, most hops I have seen is about 35).

So first, if you have any suggestions about which algorithm to use, please let me know, but I am currently thinking A* with a bounding box of the start/end points plus some buffer based on the distance expected. I am hoping any of them are a good fit for this, although obviously looking for the fastest.

Second, I followed the tutorials and tried the dijkstra algorithm (A* setup still running right now) and didn't get good results. Instead of a nice short route I expected I got a whole bunch of random links over a very wide area.

Looking at a very simple example, it appears to be because the navteq geometry isn't always aligned with the same left to right start/end orientation. Instead it has two fields showing what nodes it connects to and a field indicating the direction. One of the nodes is called a reference node, the other a non-reference node. The direction can either be both ways or towards the reference node,or from the reference node. I'd like opinions, but it appears I need to swap the source and target for the ones with a direction towards the reference node for them to be consistent. I am not sure about the both ways ones, other than I need to split those up into two directed links for other reasons already so I will probably do that first.

But since the data already has the nodes defined I was thinking of generating the source/target ids based off that instead of the geometry anyway as it is supposed to be precise. However I have the same challenges with the nodes and directions I think.

Also some randoms questions if you don't mind

Which is the best place to get help - here or the mailing list?

When I installed I didn't have lwpostgis.sql so I used postgis.sql - is this ok?

I can't seem to find how many meters or feet are in a degree (EPSG:4326). I'd like to get a better feel for the tolerance numbers.

TIA, charles

  • Message #1378

    Hi Cahrles,

    Indeed, many questions in one topic. Hope not to forget to answer the important ones.

    • Algorithms don't really matter that much (as wee actually expected). It's all about how much data you select from the database to take into account. So don't forget the bounding box if your data is large and don't forget an index on the right attributes
    • I prefer Shootings Star because it routes from road link to road link intead of from node to node. But it's personal preference.
    • Wrapper functions give you a more nicely formatted result
    • If the topological information of the Navteq data is correct and fits with what pgRouting requires, then you don't need to run the "assign_vertex_id" topology function. Nevertheless I often do it, because it also renumbers the start/end nodes and it's good to have them start with 1 and don't become too high.
    • I don't know about postgis.sql, because I don't know well about Windows version ;-)
    • For me feet are something hard to imagine, but the conversion between degree and meter depends a bit where you are located. For the tolerance level for good data it should be fine to take a few meters. Or if it's correct for sure, just make it much smaller. Degrees should be always a very small number.
    • It could be a good idea to post to the mailing list, because people then get notified by email, so the chance is higher to get an answer from other people as well, I suppose.
    • Message #1381

      Thanks Daniel

      I guess I'll try the mailing list if I have any more questions as I would like notification - I only now checked for a response :)

      I re-ran assign_vertex_id (it doesn't reset the sequence btw) with a tolerance of 0.00001 and got better results I think. Not sure exactly how many meters this is (NJ, USA) nor how to validate the results either (maybe run with another algorithm and compare), but i'm more optimistic about this.

      Also still confused about the start/end points not being the same direction but I guess if it works, it works :)

      thanks again, charles

      • Message #1382

        I did some calculations and at least at the equator the earth's circumference is about 40,000km so a degree is about 111km. A tolerance of 0.00001 would give me 1.1m (but in NJ I assume something around 1.5m maybe). Close enough to get an idea of what the numbers mean, thanks.