Re: [Tagging] navigational aid relation
Am 14.06.23 um 09:47 schrieb Frederik Ramm: Hi, "navaid" may not be the best term since it is used in aviation for actual physical installations that help with navigations, like radio beacons or lights. I am also concerned about the verifiability; is there not a danger that people will disagree about what the "best" way is to reach something? Hi there, I'm not thinking about anything that would have to be used in every address, but in cases where there are really wrong routings. I live at a place where increasingly people (craftsmen, delivery services) don't find our address because the building is closer to another street than to the street with the entrance. And there is no possibility to get to the house from this other street. In this case it is a very easily verifiable information. Go to the street with the correct name, look for the correct house number and see the entrance. This is in this case the "best" way to reach it (and in this case the only way). But this matching of street name and routing is not easily done from the OSM-data, and not done by any routing application based on osm at all. (I guess google maps uses additional information about the "best point", not available in osm). And: there are cases where the access is not from the street of the address. (Usually you have signs like "for xyzstreet 5-7 use entrance from abcstreet", sometimes a little map). Have you considered to, instead of using a relation that links sources and destinations (and btw I'd swap the terms in your examples) simply placing a node on the street network that is tagged as an "access point" for a certain address, without the relation and all? IMHO that could be a possibility, allowing for the use of the addr:xyz tags on points of a highway. But that could result in several very close points for places, where you can reach several addresses from just single point of the highway, eg. terraced houses. Greetings Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] navigational aid relation
Hi there, I just tried looking from the other perspective: Why is it so difficult to extract proper routes from the osm data and what has already been tried. I just looked over the the issues and some first-sight information on github and have seen that we're facing two different problems here: The first thing is to find the proper coordinates of the routing destination (job of Nominatim: https://github.com/osm-search/Nominatim/issues/536 Open issue since 2016 - the statement by lonvia that nominatim didn't take any entrance information into account seems to be outdated). The other thing is to find the appropriate route once you have found the proper coordinates, which can be complicated if access rules block the most suitable way. The solution of the second problem could be via the first point: just only try routing to a suitable public access point to the destination - then you can give coordinates where you can do a routing to. For the first problem it is quite already solved as nominatim returns the coordinates of a simple node with entrance=yes and an addr: information. You only would have to change the wiki page Key:entrance and encourage people to allow single nodes with the tag entrance=yes and addr:xyz (like this: https://www.openstreetmap.org/node/10979019687) if it is not obvious where the entrance to the property is. (What happened before for the whole row of houses you still can see if you plan a route to "Am Rehwinkel 19, Bielefeld" (from the point you are led to you don't see any entrance nor the house due to a high hedge, and you sometimes see people walking down the Voltmannstraße looking for entrances... Difficult, because you would have to turn in "Am Rottmannshof" to get to "Am Rehwinkel" ;-) ) Maybe an easy solution would be just to use the access-tags here possibly introduce some additional tags for "entrance". In some situations this would be a wider sense of "entrance" (in this examples at any place there is a gate, but it works even without the mapping of a gate and is still correct in the narrow sense). But even without an distinct entrance it could be some kind of an entrance if you have to leave your vehicle and enter an area of another transport mode like walking. Greetings, Sebastian Am 15.06.23 um 09:34 schrieb Minh Nguyen: Vào lúc 00:26 2023-06-14, Florian Lohoff đã viết: Management Summary: In navigation/routing the point the router is routing to is the nearest point on the routable network from the poi/address we like to navigate to. The nearest point may not be a location where the address/poi can be reached from. I suggest a navigational aid relation hinting the link between geocoding and router to use a different point on the routable network. I agree that there is a need for geocoders to produce more routing-friendly locations than the centroid. Navigable points are nothing new in the field of location services. Most geocoders already do this, including some that are often used with OSM-based maps, although none are open source as far as I can tell. I've written something of a white paper on the subject of navigable points. [1] The short story is that most scenarios would be well served by micromapping in OSM combined with some clever heuristics in the geocoder, without the need for a new relation type. I've provided some example OverpassQL queries to prove the concept, but in reality a serious data consumer would perform spatial queries or traverse the relation hierarchy more directly, without the help of a separate API. With this heuristics-based approach, we can take advantage of the large and growing body of data that's implicitly optimized for routing. Mappers generally wouldn't have to familiarize themselves with routing engines; they can just map what they observe, but in greater detail. When none of the heuristics applies, the last resort can be a site relation, using each relation member's role to clarify why the application might want to present the member as an option. I've used site relations in a few cases where a spatial query won't turn up any useful results. For example, a nearby American football stadium [2] has multiple parking lots, but all of them are off-site, on the grounds of an amusement park, a college, and some office parks. A driver would only be interested in the parking lot that corresponds to the ticket they purchased. The parking lots are members of a site relation with the stadium. [3] We have no hope of precisely modeling ticket classes in OSM, but the application can simply list the lots by name and let the user choose manually. Unfortunately, I'm unaware of any OSM-based data consumer that implements these heuristics, but routers aren't the only reason to map building entrances or site relations. [1] https://wiki.openstreetmap.org/wiki/User:Minh_Nguyen/Navigating_between_entrances [2] https://www.openstreetmap.org/way/296503400 [3] https://www.openstreetmap.org/relation/14507813 __
Re: [Tagging] navigational aid relation
Am 15.06.23 um 18:38 schrieb Minh Nguyen: Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết: You only would have to change the wiki page Key:entrance and encourage people to allow single nodes with the tag entrance=yes and addr:xyz (like this: https://www.openstreetmap.org/node/10979019687) if it is not obvious where the entrance to the property is. (What happened before for the whole row of houses you still can see if you plan a route to "Am Rehwinkel 19, Bielefeld" (from the point you are led to you don't see any entrance nor the house due to a high hedge, and you sometimes see people walking down the Voltmannstraße looking for entrances... Difficult, because you would have to turn in "Am Rottmannshof" to get to "Am Rehwinkel" ;-) ) In your example, the entrance is on Am Rehwinkel not only because the address names Am Rehwinkel, but also because there's a hedge along Voltmannstraße. Ideally, a geocoder would compute a visibility graph to determine the most accessible street, blurring the lines between a geocoder and a router. The hedge is an older try to inform routers not to lead through it... The tags entrance I just added a few hours ago after reading this discussion. I omitted Am Rehwinkel 19 because I didn't know the exact location of the entrance to the property - and to leave it for illustrating the routing problems. I assume that the local delivery services rely on routers that take the nominatim data I really would like to leave it the way it is now. A quick way to correct the routings, every other way (placing ways etc. which you have to find and map) is more difficult. And if you look at the surrounding you find a house "Voltmannstraße 97" whose access is from "Am Rottmannshof" (as I remember, have to check that before tagging...). There is really no way for any algorithm to find that out if you don't give the clear information in the map data. This in fact no big problem because people can look around the corner and find the entrance... Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Streets with gradually increasing widths
Am 15.08.23 um 14:56 schrieb Greg Troxel: If there are no objections, I'lpl add a section about the above to the wiki. I strongly object, because a data router that uses just width will conclude that the way is usable when it is not. It is a basic principle of tagging that data consumers that read the basic tags rather than the more complicated tags that are less used should not be misled. Agree completely. If you want to keep "width=" as the minimum width over the way, and then add the other things, then I don't see that as really helpful in the grand scheme, but I don't see it as harmful. I expect very few circumstances where it is appropriate, almost no one to tag them, and almost no routers to implement it. I would add: I expect many situations where data will be destroyed afterwards: If ways are split for whatever reason, this would result in two ways with identical start and end values describing another situation. (e.g if you have start=2m end=3m you will get the same section as 2m-3m/2m-3m). You couldn't split a way without measuring the width at the splitting point - as a mapper you would have to delete the width:start/end tags if you split a way without knowing the width on this point, but no one would dare or be aware of it. => "... I expect many [or at the moment: all] editors that would destroy the data." Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Streets with gradually increasing widths
Am 16.08.23 um 06:33 schrieb Kashish via Tagging: Thanks for the responses, everyone. It's not too important to me that we use the median width for width=*, so if we use width:start=*/width:end=*, we can continue using width=* for the minimum width. Tagging way nodes with width=* or width:carriageway=* was actually my first attempt at a solution, but I preferred pbnoxious' suggestion of width:start=*/width:end=* - that way, what is arguably a property of the way is associated with the way rather than its nodes. There's another issue - way nodes may be shared by multiple ways, resulting in ambiguity. The workaround of splitting up the way at different points and adding different width=* tags to each segment is inelegant, but has many things going for it - namely compatibility with existing routers and preventing existing editors from messing up data. Now I'm thinking of documenting two solutions on the wiki - 1. width:start=*/width:end=*, optionally with width=* for the minimum width of the street, and with a word of warning about the results of editors splitting ways. I'd really discourage this. The word of warning is useless. Whom do you want to warn? The mapper? The data consumer? The programmer of an editor? And what should each one do precisely after having been warned? The data in such tags just won't be reliable. Splitting of ways is very common. Just think about the algorithms you would have to implement to check the validity of the tags width:start and width:end: for using the data you would have to go back in the history to the time where the tags were set initially, then look for the consistency of the way. Then you would need an algorithm to estimate the width at the splitting point. Just assuming that the width has a linear relationship to the length of the way, you would have to calculate the length of the parts of the former way to calculate this estimate. Then maybe you would like to rewrite the corrected data to the osm database? (read about automated edits!) Or would you like the editors to do this calculation? But: the values at the splitting point are no more measurements but extrapolations, you should document this in the data. source:width:start=extrapolated ?!?! or adding an automated fixme=width estimated automatically, please measure again on the ground. This seems a lot of automated data needed with little use and less accuracy. The suggestion of putting width=xyz into a node looks better at first sight, but doesn't work for nodes at crossings. But this would be not so bad, in the algorithms you only need to ignore a width-tag on a crossing, by the cost of checking for multiple usage of a certain node by different ways. Cheers, Sebastian 2. Splitting the way and using existing width=* etc tags on the segments, and noting the benefits of this approach. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] advices about multiple values have inaccuracies , between several pages
Am 11.10.22 um 14:17 schrieb Marc_marc: Hello, I find that advices about multiple values have inaccuracies between several pages : https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values Properties can have a large number of possible values my reading : key=yes/no value aren't a propertie, it's the value for another key (for ex asia=yes/no is not a good idea, it's a value for cuisine=asia 2) Properties can have a large number of possible values key with only =yes/no value aren't a propertie, it's the value for another key Just want to emphasize that boolean values are really useful and necessary - and in use without being questioned. If you have a property that has the character of a set of features out of a quite small finite set, which exist simultaneously, then you have two possibilities: Using property=feat1;feat3;feat4;feat9 or split that into feat1=yes; feat3=yes; feat4=yes; feat9=yes. Depending on defaults you could simplify in the second method: if feat1,2,3 are yes by default, the tagging could be: feat2=no; feat9=yes. This is the theory, in reality you have it for example in: bicycle=yes and foot=yes and so on. I think the first method is more error prone and more difficult to maintain. If I check an object just for some aspects it's easier to edit just these aspects. And the evaluation can focus on the features of interest instead of parsing through more complicated tags. (Still computers work on 0s and 1s!). If you look at the sometimes complicated discussions about the access=* tags, you can clarify things in cases of doubt easily with additional boolean tags without checking wikipages (often with conflicting definitions in different languages) for the default meanings. It depends very much on the things you want to describe (and the clarity of the main tag), which tagging scheme you choose. (bicycle=yes is clear for highway=*, but very unclear for e.g. tourism=artwork, artwork_type=sculpture, even if the sculpture is a bicycle). Cheers, Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] When is I oppse vote invalled
Hello, I agree Andy nearly completely, but I would recommend Brecht to create the wiki page for the tag https://wiki.openstreetmap.org/wiki/Key:virtual_tour with maybe a link to the proposal and information that the discussion is ongoing, and a short comment on what you intend by the key and what not, even at this point. ... because: Am 18.11.24 um 16:29 schrieb Andy Townsend: Hello, On 18/11/2024 14:00, brecht devriese wrote: [...] > So it is normal that it cannot be found in taginfo as it has never been used before This actually isn't normal. One of the reasons that OSM got to where it is today, leaving numerous other "free map" competitors by the roadside, is that people mapping things in their neighbourhood don't need to go through some "tag approval" process for a new thing that they have just seen, they can just make up a tag and continue mapping. Later, if it turns out that a better tag is already in use elsewhere for exactly the same thing, it's easy to change the tag the tag they used to the more popular one. It is NOT easy, to change the tag, if you don't have a definition of it and the usage has gone too far. You would have to do mass edits. E.g. there is an overlap between information=route_marker and information=trail_blaze . You could make a distinction, but you some people don't, automated edit's not advisable... (Different uses dependent on hiking/bicycle and just regions https://overpass-turbo.eu/s/1Uly Big dots route_marker, small dots trail_blaze, red=hiking, green=bicycle, black undefined or other). There's a wiki page all about the process: https://wiki.openstreetmap.org/wiki/Any_tags_you_like . > Meanwhile, I have used this tag for 4 objects, so this tag now does show up in taginfo. That's great - https://overpass-turbo.eu/s/1UkZ - that's how new tags get established in OSM. Of the people voting one person (not me) has objected to the tag on philosophical grounds, based on what should and what should not be in OSM, and one person (me) thinks that "voting" for this sort of very low-use tag introduces a level of bureaucracy that is unhelpful to OSM as an ongoing project. +1! Of course, it makes total sense to discuss your suggested new tag (as you did at https://community.openstreetmap.org/t/rfc-proposal-of-tag-virtual-tour-url/120965 ). Different people have different views about how much discussion and how much "tag approval" bureaucracy there should be; that's absolutely fine. It doesn't mean that some people are "wrong" if they disagree with you (or me) about some things; I've been wrong about plenty of things in the past and I'm sure you have too. +1 Best Regards, Andy finally - my opinion: invalidating an "oppose" - vote is unnecessary Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
