Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 15:54:36 +0100, Dave Stubbs osm.l...@randomjunk.co.uk wrote: The first thing I thought of when reading this is, to use a relation. 'Relations are not categories' applies to people making relations out of all hotels or All hotels in London, doesn't really apply here. type=zone name=Dublin Centre maxspeed=20kph parking=no Where zone is a known geographic area? A bounding way with tags like: zone = restriction maxspeed = 20kph parking = no seems like the best way to do it to me if you don't want to just replicate the tags on everything (and I can understand why you wouldn't want to do that). There's no software that'll pay attention to it atm, but then it's not long ago that everything ignored route relations too. I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. I completely agree here. A polygon is a simpler, easier to evaluate, to tag and much, much less error-prone way to do this compared to a relation that has all ways in that area as members. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wed, 13 May 2009 17:08:51 +0200, Ben Laenen benlae...@gmail.com wrote: I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
marcus.wolsc...@googlemail.com wrote: Sorry to say that but if there are ways within the zone such as bridges and tunnels that are not affected, then this is not a zonal restriction at all. That's ridiculous. It's very possible for a bridge/tunnel to *cross* a zone, while not being part of the zone itself. E.g. an elevated motorway going over some ground-level zone, just isn't part of that zone. Even if that bridged/tunneled road had an exit into the zone, zonal regulations would only start (or end, for that matter) at that point. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
marcus.wolsc...@googlemail.com wrote: I completely agree here. A polygon is a simpler, easier to evaluate, to tag and much, much less error-prone way to do this compared to a relation that has all ways in that area as members. Inclusion tests (especially if even a way segment can be intersected by the area polygon) are easier for evaluation than direct membership references? I doubt that this is usually correct. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Thursday 14 May 2009, MP wrote: Except it's not a geographic area, but rather a set of streets with that restriction. If a bridge or tunnel without the restriction goes over/under a street with the restriction you'll have a problem. In that case, that bridge can have differen speed limits set directly on the way. Just define that tags on individual ways override tags set in the zone and this will solve the issue. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. I've seen many zones with some limitations (mostly speed limit or some parking limitations), but such zones rarely contain any bridges or tunnels. If they do, they can be either tagged individually, or we can also make new relation that will contain the zone and roads that are NOT in the zone (relation containing those few exceptions like the bridges, tunnels, etc ... so they won't need individual tagging) And who's going to think about that? You're not exactly making it easy for a mapper if he or she has to know about features you're not able to see on the road he has just explored... I'd suggest one should tag a road with features found on that road and not with features that are missing on the road. And these situations are more common than you may think. Built-up areas are the most common where such a thing happens here as they're of course the largest kind of zonal restrictions, and each city will have it's roads crossing them without being part of it. But I've also seen it with zones with parking restrictions or zones with speed restrictions. And you just can't tag the road with for example an overruling maxspeed tag, as the road may just have its default maxspeed in which case you don't tag that speed. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On 14 May 2009, at 11:55, Ben Laenen wrote: On Thursday 14 May 2009, MP wrote: [..] And these situations are more common than you may think. Built-up areas are the most common where such a thing happens here as they're of course the largest kind of zonal restrictions, and each city will have it's roads crossing them without being part of it. But I've also seen it with zones with parking restrictions or zones with speed restrictions. And you just can't tag the road with for example an overruling maxspeed tag, as the road may just have its default maxspeed in which case you don't tag that speed. Yeah but the default maxspeed becomes the one of the zone. So the road would then need a specific restriction, or the zone would need to be split. The following evaluation hierarchy could be used: 1. Use the default restrictions for that type of road. 2. Is a road in a restriction zone? Use those restrictions instead of in 1. 3. Does the road have a specific restriction on it? USe that instead of 1. and/or 2. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On 30/04/09 13:17, Pieren wrote: On Wed, Apr 29, 2009 at 8:27 PM, Greg Troxel and you define the relation to say that all ways in some area of some type should be in the relation. You try to use relations to define a category but : http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories The first thing I thought of when reading this is, to use a relation. 'Relations are not categories' applies to people making relations out of all hotels or All hotels in London, doesn't really apply here. type=zone name=Dublin Centre maxspeed=20kph parking=no etc. Rory signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
2009/5/13 Rory McCann r...@technomancy.org: On 30/04/09 13:17, Pieren wrote: On Wed, Apr 29, 2009 at 8:27 PM, Greg Troxel and you define the relation to say that all ways in some area of some type should be in the relation. You try to use relations to define a category but : http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories The first thing I thought of when reading this is, to use a relation. 'Relations are not categories' applies to people making relations out of all hotels or All hotels in London, doesn't really apply here. type=zone name=Dublin Centre maxspeed=20kph parking=no Where zone is a known geographic area? A bounding way with tags like: zone = restriction maxspeed = 20kph parking = no seems like the best way to do it to me if you don't want to just replicate the tags on everything (and I can understand why you wouldn't want to do that). There's no software that'll pay attention to it atm, but then it's not long ago that everything ignored route relations too. I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wednesday 13 May 2009, Dave Stubbs wrote: Where zone is a known geographic area? A bounding way with tags like: zone = restriction maxspeed = 20kph parking = no seems like the best way to do it to me if you don't want to just replicate the tags on everything (and I can understand why you wouldn't want to do that). Except it's not a geographic area, but rather a set of streets with that restriction. If a bridge or tunnel without the restriction goes over/under a street with the restriction you'll have a problem. I really wouldn't recommend relations for specifying what things are inside an area. It's a waste of two entire dimensions our dataset happens to have. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
Except it's not a geographic area, but rather a set of streets with that restriction. If a bridge or tunnel without the restriction goes over/under a street with the restriction you'll have a problem. In that case, that bridge can have differen speed limits set directly on the way. Just define that tags on individual ways override tags set in the zone and this will solve the issue. So while it may work for many zonal restrictions to use an area (although even then there are still issues) you need another way as well due to the bridge/tunnel issue, and that other mehod can only be relations. I've seen many zones with some limitations (mostly speed limit or some parking limitations), but such zones rarely contain any bridges or tunnels. If they do, they can be either tagged individually, or we can also make new relation that will contain the zone and roads that are NOT in the zone (relation containing those few exceptions like the bridges, tunnels, etc ... so they won't need individual tagging) Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Wednesday 29 April 2009, Tobias Knerr wrote: Kurt Roeckx schrieb: I'm looking for a way to map restrictions for a zone. This includes things like maxspeed, maxweight and parking restriction. I want to avoid having to place those tags on all the roads inside the zone, specially for large zones, since it's very easy to forget one. Well, - if you use tags to mark a zone, you can forget them just as easily Tags are out. You need to combine the information, and a way to add more data. Unless you like adding the same set of tags on a lot of ways of course. - adding all ways to a relation isn't easier than tagging all of them Sure, but nothing problem checkers wouldn't be able to show. - if you mark the entrances of the zone, you (or someone adding a track leaving the zone) can forget an entrance, which is much worse than forgetting a single tag because this error might affect areas far outside the zone I think though that marking the boundaries with nodes could be used by some JOSM plugin to automatically create the zone relation. After that it's a matter of problem checking. - polygons indeed can save work, but suffer from problems e.g. with layered roads And the problem that you don't know how to draw the polygon in the first place, if say you've only mapped part of the zone. So will you then guess to where it extends? And if not, how do you know later on the polygon isn't correctly placed? And at what places it's not correctly placed. And what if someone draws a road not part of the zone which curves a bit into the polygon you drew but forgets to replace the zone polygon, or doesn't see it? Etc. The advantages of zonal mapping for quality are, however, only minor. I beg to differ. Zones often need something extra, like names or reference numbers. And if your zonal restriction is the equivalent of five tags on each way, I'd rather have that in one place instead of everywhere. Forgetting a tag on a single way isn't that much of a problem. It will either have only minor effects or be easily spotted by someone. This, in my opinion, isn't enough to compensate for the potential problems: - zonal mapping can be harder for newbies to understand, depending on editor support. Making simple road attributes hard to understand is a no-go. Just a matter of documentation. There are a few countries on the wiki that have their traffic signs listed and their translation to OSM. I also don't understand why it is harder for newbies in the first place. Is it because it might be solved with a relation? - zonal mapping makes it more difficult to write software evaluating the information, so less people will be able or willing to create cool stuff with OSM. Those who still do will have less time for other features. Let's assume that one day the incredible OSM library will appear that will solve things like I have vehicle type X, what are the access rules on this street? You now sound like it's trivial as it is now, but it's actually surprisingly difficult to interpret a lot of tags already, and all countries have their own interpretations and rules as well on top of that. - some options for zonal mappings (such as polygons) have performance disadvantages. This makes providing OSM services more expensive or causes slower software. You process the data before using it. You're not uploading OSM data in the xml format from the API directly into your gps either. When routers use the data it's also by processing the data first to make it usable to calculate routes. And that's the real issue here: you want the data instantly ready, but that's not how the data should be in OSM. We map the world, if there's a zonal restriction, we map it as such. Therefore, I suggest that you map zones _in addition_ to directly adding tags with the information to the streets. Duplicate tags are always a bad idea. This serves your stated purpose of avoiding errors: Zone information can be automatically compared with tag information to make sure that all streets in the zone have the required information. But what if a street in a certain zone overrides those zonal restrictions with some other signs? Just don't tag ways with the zonal restriction unless you specifically tell it's zonal. It would even be possible to create editor plugins for the task of adding the zone's tags to the streets inside it on demand. That's basically the worst thing you can do. If that happens I'll use it to tag all roads inside a country with is_in=country X, or rather with is_in=country X,continent Y. There's just no need for it, as it is tagged already, and the translation of tags to something a certain program can use should be done after getting the data from the API. But in OSM, the data should resemble what's on the ground. If your purpose is to make a program that shows the traffic signs on a little screen on your gps, this kind of data is important. Most of this
Re: [OSM-talk] Zonal restrictions.
On Wed, Apr 29, 2009 at 8:27 PM, Greg Troxel and you define the relation to say that all ways in some area of some type should be in the relation. You try to use relations to define a category but : http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
I'll focus on the coexistence vs. zone-only aspect, because most of the other problems can indeed be solved or mitigated by choosing a decent zone representation and throwing in some editor support and documentation. Ben Laenen wrote: - zonal mapping makes it more difficult to write software evaluating the information, so less people will be able or willing to create cool stuff with OSM. Those who still do will have less time for other features. Let's assume that one day the incredible OSM library will appear that will solve things like I have vehicle type X, what are the access rules on this street? So you assume that well-designed, liberally licensed (!= GPL) Open Source libraries will exist for all major programming languages and platforms soon? Well, until then, I'll continue to assume that the goal of OSM data being used in creative and unexpected ways is better served by keeping complexity as low as possible instead of adding some more layers of code. - some options for zonal mappings (such as polygons) have performance disadvantages. This makes providing OSM services more expensive or causes slower software. You process the data before using it. You're not uploading OSM data in the xml format from the API directly into your gps either. When routers use the data it's also by processing the data first to make it usable to calculate routes. I'm fully aware of that. It's that very processing process that will be slowed down. It's hard to quantify with no real information available, but software that requires frequent updates (rendering, maybe even live rendering) surely won't get faster by adding more preprocessing. And that's the real issue here: you want the data instantly ready, but that's not how the data should be in OSM. We map the world, if there's a zonal restriction, we map it as such. You make it sound as if adding a maxspeed to the road in addition to mapping a maxspeed-limiting zone would somehow not be mapping the world, when it's really just a different (and more conveniently usable) way of representing reality. Therefore, I suggest that you map zones _in addition_ to directly adding tags with the information to the streets. Duplicate tags are always a bad idea. Redundancy are not necessarily a bad idea if it helps to avoid errors and make processing easier. Also, it's good practice in OSM to add detail _without_ making access to less detailed information harder. That's why we have things like highway=service + service=driveway. The redundant highway=service in this example serves the sole purpose of letting users of the data that don't care for details handle all service ways in a similar manner. Similarly, details about the reason for a restriction (e.g. a zone) should be added in a way that doesn't require additional effort by users of the data who don't care for that additional information. But in OSM, the data should resemble what's on the ground. If your purpose is to make a program that shows the traffic signs on a little screen on your gps, this kind of data is important. So your program wouldn't work if zone information were present in addition to, rather than instead of, traditional way tagging? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
On Thursday 30 April 2009, you wrote: So you assume that well-designed, liberally licensed (!= GPL) Open Source libraries will exist for all major programming languages and platforms soon? Well, until then, I'll continue to assume that the goal of OSM data being used in creative and unexpected ways is better served by keeping complexity as low as possible instead of adding some more layers of code. Well, short answer: yes, I do assume that library will be made one day. Longer answer: currently we have such a thing in all software making use of OSM now, each with it's own interpretations, which aren't necessarily correct (and I'm sure it often isn't). So do we just let all those programs develop their own code (which may be incorrect, certainly not correct for the entire world concerning all different tagging methods in each country) or do we do what makes sense: make one library for all to use. And what the form of that library should be, I don't know. That's open for discussion. I'm fully aware of that. It's that very processing process that will be slowed down. It's hard to quantify with no real information available, but software that requires frequent updates (rendering, maybe even live rendering) surely won't get faster by adding more preprocessing. You're really making a problem out of nothing. I'll assure you that this will add practically no extra time. These are simple rules that take virtually no time. Perhaps the main calculation problem is that you need to go from country boundaries to the roads inside it since you need to know what set of rules apply. But that's not some specialty from this library, all programs should do that right now already (but don't) to know default speed limits and access rules. You make it sound as if adding a maxspeed to the road in addition to mapping a maxspeed-limiting zone would somehow not be mapping the world, when it's really just a different (and more conveniently usable) way of representing reality. Only in your definition of convenient and usable. IMHO it's much more convenient to tags zones as one entity since it can then refer to for example municipality decrees which in turn helps to maintain it later on. Redundancy are not necessarily a bad idea if it helps to avoid errors and make processing easier. No, redundancy is always a bad idea. Tags will eventually start to contradict each other, and removing redundancy will improve maintainability. Also, it's good practice in OSM to add detail _without_ making access to less detailed information harder. That's why we have things like highway=service + service=driveway. The redundant highway=service in this example serves the sole purpose of letting users of the data that don't care for details handle all service ways in a similar manner. Similarly, details about the reason for a restriction (e.g. a zone) should be added in a way that doesn't require additional effort by users of the data who don't care for that additional information. Granted, and I've added a few times a tag like maxspeed:zone=yes as well. But from the moment we're talking about slightly more complex zonal restrictions, we end up adding the same set of tags to a lot of ways, and then the only sensible thing to do is to remove duplication and put it together, which in this case is a good thing (and doesn't have anything to do with relations as categories) since the situation in real life combines it together as well in one zone. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Zonal restrictions.
Hi, I'm looking for a way to map restrictions for a zone. This includes things like maxspeed, maxweight and parking restriction. I want to avoid having to place those tags on all the roads inside the zone, specially for large zones, since it's very easy to forget one. What currently comes closest to what I want is an area with a place= tag, but the meaning of that is not clearly defined, and you can't do everything with that. So I want to have a way to mark all roads inside the zone to have the restriction for that zone. It should probably also have a way to indicate that you're inside the built-up area. If the same type of restriction (for instance maxspeed) is placed both on the zone and the highway itself, the one for the highway should be used. For a previous discussion about this, see: http://wiki.openstreetmap.org/wiki/Talk:OSM_tags_for_routing/Maxspeed#Inside_.2F_outside_built-up_area Kurt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
What currently comes closest to what I want is an area with a place= tag, but the meaning of that is not clearly defined, and you can't do everything with that. I think what you really want is an implicit relation, where the road ways inherit maxspeed from the relation, and you define the relation to say that all ways in some area of some type should be in the relation. I'm a little worried that this will get too complicated, but heading down the path: Define a polygon (er, closed way) to denote the area for which ways get the inherited properties. I think this notion is just about tag inheritance and not tied to any administrative boundary. For example, in Mass in the US we have the notion of thickly settled (businesses on both sides, houses close together) where the speed limit is 30 mph and otherwise it is 40 mph. You could capture these with polygons to save tagging time, but there is no defined district. On the polygon put a maxspeed tag. On the polygon put a special inverse_relation tag that somehow defines how to match ways within the polygon that the maxspeed tag should apply to. Sort of a SQL select statement :-) Convince all the routing (and renderers that show speed?) implementations to parse and use this new kind of inverse relation. Plan B would be to add editor support to put maxspeed tags on all ways of type 'highway=foo' that don't have them. So there'd be a lot of tags, but maybe easy to add. We might also want to encode maxspeed to record the rules, but also have some typical_speed to record the speed at which traffic moves when it isn't congested, extracted from tracklogs. pgpnQeKRk4UUH.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
Kurt Roeckx schrieb: I'm looking for a way to map restrictions for a zone. This includes things like maxspeed, maxweight and parking restriction. I want to avoid having to place those tags on all the roads inside the zone, specially for large zones, since it's very easy to forget one. Well, - if you use tags to mark a zone, you can forget them just as easily - adding all ways to a relation isn't easier than tagging all of them - if you mark the entrances of the zone, you (or someone adding a track leaving the zone) can forget an entrance, which is much worse than forgetting a single tag because this error might affect areas far outside the zone - polygons indeed can save work, but suffer from problems e.g. with layered roads The advantages of zonal mapping for quality are, however, only minor. Forgetting a tag on a single way isn't that much of a problem. It will either have only minor effects or be easily spotted by someone. This, in my opinion, isn't enough to compensate for the potential problems: - zonal mapping can be harder for newbies to understand, depending on editor support. Making simple road attributes hard to understand is a no-go. - zonal mapping makes it more difficult to write software evaluating the information, so less people will be able or willing to create cool stuff with OSM. Those who still do will have less time for other features. - some options for zonal mappings (such as polygons) have performance disadvantages. This makes providing OSM services more expensive or causes slower software. Therefore, I suggest that you map zones _in addition_ to directly adding tags with the information to the streets. This serves your stated purpose of avoiding errors: Zone information can be automatically compared with tag information to make sure that all streets in the zone have the required information. It would even be possible to create editor plugins for the task of adding the zone's tags to the streets inside it on demand. Most of this applies primarily to small-scale zones. I don't suggest that everyone uses tags to define which country an object is in. The built-up areas are probably a border case. I'm not entirely sure whether tagging of individual highways is a good option here. It might still be, though, because it can also serve as a I have checked for explicit access restrictions (such as maxspeeds) and there are none marker. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
