|
I've been using osm4routing to filter and formate OSM data as a graph and process it. However for my application (see 1) I don't care about the "insides" of cities (/towns/villages/..), all I need is the fact that there is a city. Filtering out residential streets from osm4routing output is easy (see 2) but this still leaves nodes which represent road junctions and similar. How can I merge all the nodes inside a city to a single node? This node should be incident to all the edges which were connected to the city. I was hoping that there was something which would help me distinguish which node belongs to a city. I tried looking at the addr key but I am not sure whether all objects inside a city have this properly assigned. The boundary information seems also plausible but again I don't know about the reliability and also this seems to be harder to do. Due to the size of the data I am of course looking for a general rule (since I can't do this manually). 1) Analysis of road network on state, or continental level, not city infrastructural level. 2) just select the lines of the edges file s.t. they have number >1 in the fifth column |
|
This is an interesting question about how to generalise OSM data. In practice there is no easy way. You could use one of the following ways to try & identify built-up areas:
I presume you are ignoring residential streets, so once you have some approximation of built-up areas linked to the actual OSM element describing the place, you need to clip the road network using the built-up areas. It is important that you identify which place a given road belongs to before clipping. This can be done by identifying which roads intersect the perimeter of each built-up area. The dangling ends of the roads are then connected to a single node representing the city (typically I'd use the existing OSM node or centroid of other elements for this). This represents a considerable amount of post-processing of OSM data, which requires knowledge of geometries. Personally I'd do this in a database such as PostgreSQL with PostGIS. An additional problem then arises because you may want the data in OSM XML format for building your graph. Mainly this involves re-working the way_nodes table for truncated ways. All additional artificial path links are not really a problem as these can be created with negative ids outside the range of ids in use. For other post-processing of OSM data for routing take a look at some other applications. Note the process as described may create inaccurate graphs (specifically a road which loops into a 'city' area and out again may be incorrectly connected to that city. |
