developer (#13) - OpenStreetMap? (OSM) network topology (#291) - Message List
Hi there, I'm quite new to pgrouting (but not new to routing algorithms). I'm working with OSM data and pgrouting seems to be the extension I need to add to PostgreSQL/PostGIS. I read the documentation and some topics in the forum with interest. I have a simple question I'd like to put to the developers regarding creating network topology onto OSM data. This workshop "FOSS4G routing with pgRouting tools and OpenStreetMap? road data" (http://pgrouting.postlbs.org/wiki/WorkshopFOSS4G2008) at this point "Load your network data and create a network topology --> Create network topology" mentions the following: "Note: The dimension of the tolerance parameter depends on your data projection. Usually it's either "degrees" or "meters". Because OSM data has a very good quality for Cape town we can choose a very small "snapping" tolerance: 0.00001 degrees". Now, network topology is implicit in OSM data. Creating OSM data is in fact creating connectivity (but I can only speak for the UK data). The OSM xml file defines a series of nodes and ways; ways are a collection of nodes. Creating a set of connectivity rules / network topology is a matter of parsing the xml file and finding what ways have common nodes (in simple terms). In my opinion there is no need of geographic functions (e.g. distance): making use of these functions would only introduce the risk of errors. Is there any reason for the use of a snapping function in the OSM case? Does anyone know if a kind of OSM xml parser/processor, as the one hinted above, exist? Thanks
-
Message #1042
Thanks for bringing up this discussion!
There are probably two reasons for having this "distance" parameter:
(1) the topology function is not only made for OSM data, so the "distance" parameter has to be set to use this function to create the tables and attributes we need for pgRouting. If you're sure that your data doesn't need "snapping" it should be OK that you set it to "0".
(2) from my experience a lot of OSM contributers don't care about topology that much. They are more drawing than digitalizing. This might not be the case in UK or Germany, where a lot of people are checking the data, but here in Japan for example you would hardly get a proper route, because a lot of roads are just disconnected even if they aren't.
Was this an acceptable answer or did I forget something? ;-)
daniel09/03/09 08:39:42 (15 months ago)-
Message #1044
1) Setting the distance to "0" only reduces the processig time (I only assume, not tested) but still use the same algorithm, thus ignoring the implicit topology of the OSM data;
2) Given the "topology oriented" OSM editing tool I always thought it was pretty hard ignoring it; it's easier to connect to existing nodes than ignoring them. But again, this is true when extending ways, I can see lazyness introducing some errors when it comes to a new "T-junction" for example. I can only believe what you say about Japan... erm... in fact I'll check by myself a couple of places I know well... I would appreciate if you could direct me to some example of bad topology, it would be nice to highlight this to the OSM forum;
Thanks a lot Daniel to get back to me on this, you definitely shed some light. I understand that my is a narrow "issue" and shouldn't take up too much space in here, but OSM data is being used more often now and, in my opinion pgrouting should take this into account. Perhaps we should assume that OSM data is topologically correct and let pgrouting "throw errors" (by comparing pgrouting results using the usual algorithm against a different algorithm (reading implicit topology) and highlight inconsistencies) and publish them on OSM; there will always be someone out there willing to pick this up and doing some corrections (including myself ;)
AndyFo09/03/09 22:54:31 (15 months ago)
-
