The .osm file I have:
// Weird part of the file
<node id="104511" lat="52.1696253" lon="0.131889"
version="3" timestamp="2013-03-05T18:51:38Z"
changeset="15262147" uid="103253" user="gormur"
/>
contains nodes that apart from latitude and longitude have
no other meaningful info (in my opinion). I have no idea whether such node is a building, a bus stop, or an intersection of two streets.
1) Why do people add such nodes into the file?
2) What's a simple way to remove such nodes from .OSM and leave file only with tagged nodes, such as:
<node id="104520" lat="52.1951248" lon="0.1312155" ...>
<tag k="highway" v="traffic_signals"/>
</node>
3) Could an untagged node indicate the intersection of 2 streets? Will I realize which streets the node intersects by looking to which ways it belongs? How can I know such node is the intersection of 2 streets rather than a building on the corner of 2 streets?
Not all nodes have/need tags.
Nodes that are part of a way (a street, a building, a forest etc.) just exist to define the geometry of that way. In that case all the necessary tags (highway, building, landuse and so on) are on the corresponding way and not on the node. A way keeps a reference to all nodes it consists of. So in order to know if a node is part of a building you have to take a look at the way it belongs to (if it belongs to a way). Also note that a node can belong to multiple ways, or to no way at all.
It depends on the specific feature if the tags are primarily used on nodes, ways or relations. Buildings for example are mostly mapped as ways, sometimes as relations and rarely as nodes. Contrary, bus stops are mostly just nodes.
For more information take a look at the OSM XML file format, OSM elements and OSM tags.
Related
Had a query regarding the OSM file's tags and values. I came across files where there are inconsistencies in tag names and certain node ids/uids do not have tag names and thereby don't allow us to identify what feature it is without opening them in any GIS software. For example, some node ids and uids have tag names as "source bing". Is there a way to identify what they represent without opening them in GIS software? Also, How does OSM recognize these features without proper tag names and values?
Thank you!
In the OSM data model, nodes can represent point features, but they can also be used to define the shape of ways (or, rarely, relations). OSM ways do not have location information on their own, but instead reference a list of node IDs. You can read more about this in the OSM wiki's article on nodes. The OSM wiki is also a good source on the meaning of the tags used in the OSM database.
Nodes that do not represent a point feature will usually carry no tags. However, you will sometimes find nodes with tags for internal use by OSM contributors, such as source information.
There are other reasons why a node may have no tags or unexpected tags, such as editing mistakes by an OSM contributor or newly invented tags. But these are comparatively less common.
I'm trying to find out the type of a crossroad / intersection in overpass by given coordinates (simple 4-way-crossroad or 3-way-intersection aka Y/T intersection).
Wanted to count the way-id's I'm getting via json later in program code (4 = simple crossroad, 3 = Y or T) using the following query:
http://overpass-turbo.eu/s/NyD
[out:json][timeout:15];
way["highway"](around:1,48.7986003,11.3759673);
foreach ->.w {
node(w.w);(way(bn);- .w;)->.wd;
out body geom;
};
Problem: This only works if a street ends at the crossroad / intersection or at least turns into another way-id.
In this example there's a street which reaches from north to south and east. The east way got another way-id so that's not a problem. But from north to south it's just one way (so only one id). Result: I'm counting 3 but it should be 4 for this type of crossroad.
How do I solve this problem or is there a better way to identify the type of a crossroad / intersection?
Thank you very much!
You have to look at the junction node, too.
Some examples:
If the node is part of two ways and..
these ways have other nodes before and after this node ID then you have a 4-way-junction.
only one way has other nodes before and after this node ID then you have a 3-way-junction
none of these ways have other nodes before and after this node ID then it is not a junction. Instead, the way continues with a different ID.
If the node is part of n ways and it is the last or first node of all these ways then you have a n-way-junction.
There will be some more cases than the ones mentioned above. Take a sheet of paper, draw some ways and their nodes onto it to get a better visualization of the data.
I'm not sure if this simple approach will work for all cases, though.
does anybody know if there is a way I can seperate only the crossroad nodes which are included in a .pbf file? Is this clue (if a node is crossroad or not) included in this file's format?
Another option to solve your issue would be to use the new Atlas project.
As part of loading .osm.pbf files into in-memory Atlas files, it takes care of doing way sectioning on roads:
Load your pbf file into an Atlas. You will then have an Atlas object that you could save to a file and re-use.
Use the Atlas APIs to access all the intersections
In the end, each Atlas Node which is connected to more than 4 Edges on a two-way road or 2 Edges on a one way road would be a candidate if I understand your question correctly.
I'm not aware of a ready-made solution for this task, but it should still be relatively easy to do.
For parsing the .pbf file, I recommend using an existing library like Osmosis or Osmium. That way, you only need to implement the actual semantics of your use case.
The nodes themselves don't have any special attributes that mark them as crossroads. So instead, you will have to look at the ways containing the nodes.
Some considerations when implementing this:
You need to check the way's tags to find out whether it's a road. The most relevant key for that is highway. The details depend on your specific use case – for example, you need to decide whether footways, forestry tracks, driveways, ... should count.
What matters is the number of connecting way segments at a node, not the number of ways. For example, a node that is part of two ways may be a crossroads (if at least one of the ways continues beyond that node), or may not (if both ways start/end at that node).
I used the spatialite_osm_map tool to generate a spatialite database from an .osm.pbf file. After the process was finished, a series of tables were generated in the database as shown in the image.
I noticed that there were 3 groups of tables based on the prefixes of their names: In_, pg_ and pt_. I also noticed that the rest of the name corresponded to a key defined in OpenStreetMap.
Can someone explain to me how the information is distributed in each of these groups and tables? I've searched for a site that explains the resulting schema after the conversion, but I've only found information on how to use the tool.
I think you have already identified the key points of this scheme.
It's main purpose is to offer the data from OSM in a way who could be more direct and intuitive for a GIS user. The data is splited according to OSM tags (aerialway, aeroway, amenity, etc., you can change the list of tags to be used if you don't need all of them) and according to the type of geometry (pt_* for points, ln_* for lines, and pg_* for polygons) so these tables (which could be directly seen as "layers" by a GIS user) can quickly be styled (for example in a GIS desktop application such as QGIS) with simple rules due to this simple schema (for example one can set rules like green for pg_natural, blue for ln_waterway and pg_waterway, or just click on the "pg_building" layer to toggle its visibility). That schema doesn't preserve all the objects from the OSM database, but only those requested to build the tables for the requested tags.
Contrary to the original way of storing OSM objects, with this kind of extraction you will lose the relationships between objects (for example in OSM the same node can be used, let's say, as part of the relationship describing an administrative boundary and as part of a road; here you will get a road line in ln_road and a polygon in pg_boundary but you will loose the information that they were maybe partially sharing nodes). Notably due to this last point, the weight of the OSM extractions can be relatively high compared to the original file.
So I guess that this kind of scheme (which is one amongst other existing ways to transform OSM data) offers an interesting abstraction for those who are not accustomed to the OSM schema which use Node, Way and Relation elements (eg, in OSM, buildings can be represented as closed way or as relation, here you get "simply" polygons for these various buildings).
I've been playing around with API, XAPI and Overpass of OSM. But I can not get some info a need: to get all information nodes of a street.
Here a example:
http://www.openstreetmap.org/browse/way/5671291
This gives information of a way called "Watts Street" (in NYC), but it's not all the street, just a part of it.
The other part:
http://www.openstreetmap.org/browse/way/46116390
This happens with some streets, that are split in different OSM "ways"
Is there a way to get all the nodes of a same street having more than "one way" to get all the coordinates across that street ?
Thank you
You could try to query the street name and get all ways with the same name. Then you could take all individual nodes and you should have what you want. I know Nominatim does that mapping but I'm not familiar with the api's you mentioned.
Another (maybe more cumbersome) method is to look at the nodes of your way and see in what ways they are involved. If you take your example, the node 42426060 is part of both ways you're looking for. If you could query the ways for that node and match them (according to name), you could merge them yourself.