Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
On 23/05/12 13:19, Gregory Williams wrote: > If we need to show that an ASL is just for certain classes of traffic then > I'm sure we could just use the normal access tags, i.e. bicycle=yes, > psv=yes, etc. That's an overloading of meaning, I think. The access tags are for noting legal access[1], and in the UK at least all bicycle ASLs can be used - crossed, or stopped at - by motor vehicles too. In fact, they're required to stop at them should the lights change to red while they're inside the marked area and able to stop within it safely[2]. [1] With the significant exception of barriers. Sigh. [2] Well, *something* has to explain the taxi drivers I keep finding in them. -- Andrew Chadwick ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
On Wed, 23 May 2012, Martin Koppenhoefer wrote: > 2012/5/23 Martin Vonwald : > > >>> If I > >>> want to move the "street" I have to move seven ways. > >> why would you want to move a street that you have surveyed up to this > >> level of detail? I think this is hypothetical (and btw: it is 6 in > >> your example). > > > > Japan moved a few meters not so long ago. > > > this won't be a problem and you know this: simply move the whole of > Japan, as it is an island this is trivial (if the movement is the same > everywhere). ...It would be pretty cool to have fault lines in osm so that we could easily reposition everything after such events. :-) -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
On 23/05/12 12:50, Martin Vonwald wrote: > Before using a relation only for asl's, please think of the proposed > junction relation [1]. Maybe if the asl's are just put there, we don't > need a separate relation. I'm coming to the conclusion that relations are unnecessary for ASLs. They always exist in advance of regular stop lines by definition; when used together with them, the offset pattern should be used for the stop line and not the junction-node pattern; the combination is sufficient for determining the direction, ways being sequences of nodes and all. Of course, some updated junction relation could make use of them, same as any other object. No problem there. -- Andrew Chadwick ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Geology and landcover - Building an extension
2012/5/23 sabas88 : > Regarding the software, here [0] states the non-commercial clause. > Should this proposal require prior authorization by FAO offices? > [0]http://www.fao.org/docrep/008/y7220e/y7220e00.htm It reads: "All rights reserved. Reproduction and dissemination of material in this information product for educational or other non-commercial purposes are authorized without any prior written permission from the copyright holders provided the source is fully acknowledged. Reproduction of material in this information product for resale or other commercial purposes is prohibited without written permission of the copyright holders." I read this as: yes, we would need an explicit permission from them. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
2012/5/23 Martin Vonwald : >> So I end up with 4 ways (highway, 2 sidewalks, cyclelane), one >> relation (area) and some nodes (lowered kerbs). Of course this is more >> complex, but you also get a whole lot more of detail, > > I see it the other way around: the increase in complexity does not > justify the increase in detail. I fail to understand this sentence. Did you mean it the other way round? (increase in detail does not justify the increasing complexity?) >> especially if >> there is more stuff to take into account (geometry not perfectly >> parallel, barriers which are (partially) between the sidewalk and the >> road, ability to map barriers on the sidewalk only, etc. > If one would allow to change the width of the xway-parts, you could > map geometry that is not perfectly parallel. what exactly are these xways? How would they end up in the database? Is it another osm-feature (besides ways, nodes, rels), or is it a way with special tags? How do they relate to current ways? >>> If I >>> want to move the "street" I have to move seven ways. >> why would you want to move a street that you have surveyed up to this >> level of detail? I think this is hypothetical (and btw: it is 6 in >> your example). > > Japan moved a few meters not so long ago. this won't be a problem and you know this: simply move the whole of Japan, as it is an island this is trivial (if the movement is the same everywhere). >>> If I want to add >>> a junction I have to add a node to every way. >> Yes, (see above, really not likely that you map a street with 5 ways >> in every detail and then you discover that you "forgot" a whole >> junction). > I didn't forget the junction - it was just built. Facts changes! I don't see what is the particular problem (whether you have to integrate something later or map it from scratch), see below: >> Of course the junction will be more complex to map compared >> to a simple node, but this is also one of the reasons you are doing >> it: to get more details how the junction looks like. >>> If the connecting road >>> is also represented by seven ways I would have to connect... no, I >>> don't count now... a lot of ways. >> actually you would have to connect only those ways that are >> intersecting in reality, not all of them (see above). > > I know, but this is still "a lot" compared to "one". Well, won't those parallels in your "xway" somehow have to be connected or not as well? How do they magically intersect? >>> Now I want to add a route relation for a bicycle route. For this I >>> have to split the "street". >> not at all, you will have the cyclelane where you put the relation to >> and you will _not_ have to split the street. > Then I misunderstood the proposal. That would be good. I have to apologize for the current state of this proposal, it really isn't documented very well and I wouldn't even be astonished to find some contradictions in it. Definitely needs some illustrations and examples as well. > The way I think about it, it would be quite simple: just draw the > ways/lanes/barriers/whatever as they are, but they magically glue > together and the width of each part is automatically determined. Don't > ask me about details! I figured this out just a few hours ago. you will at some point have to tell the editor/database/dataconsumer which lanes and barriers and stuff belong together. I don't yet understand how you would achieve this, as you seem to refuse to use a relation for this. It is not possible to do it just spatially (at least not in some cases). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
The first example wasn't broken, IMO. It just shows that there are ASLs on several approaches to the same set of lights. I've fixed all of the other examples except the last one. These were mainly situations where the constituent highway had since been split and there isn't editor support for knowing only to keep the way attached to the road, thus it's easy for there to end up being more way members of the relation that there should be. I agree that you cannot determine the ASL position itself with this scheme, but that's easily rectified by using some roles. E.g. include mark the role of the junction's node as 'junction' and add a further node at the position of the ASL and mark this 'asl', ensuring that this node is a member of the way approaching the junction. If we need to show that an ASL is just for certain classes of traffic then I'm sure we could just use the normal access tags, i.e. bicycle=yes, psv=yes, etc. The only kind of example that I can think of is in an experimental traffic scheme in Canterbury at the moment where buses / taxis have an advanced waiting position for going through some traffic lights. There's also a restriction to buses / taxis for going through the lights in just that direction, so it might be argued that it doesn't add much value by recording the "bus / taxi" ASL. I'll try to remember to snap a photo of the arrangement at some point (it's post Google StreetView's visit, having only started on Mar 27th this year). I've seen some junctions where the ASL's actual position is actually quite a long way from the highway=traffic_signals node in the past, and the use of the relation does seem useful to preserve the semantics of the ASL's relationship with the junction, where the "nearest junction" interpretation on cycleway=asl might prove ambiguous or even misleading. I'll try to dig out some examples. Gregory -Original Message- From: Andrew Chadwick (lists) [mailto:a.t.chadwick+li...@gmail.com] Sent: 23 May 2012 12:02 To: tagging@openstreetmap.org Subject: Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...? On 23/05/12 10:52, Gregory Williams wrote: > There's also > http://taginfo.openstreetmap.org/tags/type=advanced_stop_line > which uses a relation containing the way approaching the ASL and the > node of the junction of the ASL. With this method it's easier to > determine the direction of approach to the ASL than just tagging a single node alone. Thanks for the reminder; we'll have to organise those too. I'm not sure they're completely consistent: http://www.openstreetmap.org/browse/relation/75707 - 3 ways, all connecting to a central node http://www.openstreetmap.org/browse/relation/87140 - 2 ways, 1 node; ways are in sequence, node is *not* part of one http://www.openstreetmap.org/browse/relation/106889 - two 2-way sequences, 1 node, 1 plain way: 6 members http://www.openstreetmap.org/browse/relation/106868 - 7 ways all in a line, 1 node http://www.openstreetmap.org/browse/relation/158262 - 1 way http://www.openstreetmap.org/browse/relation/185408 - 1 node http://www.openstreetmap.org/browse/relation/239790 I assume the model was for 1 node and 1 or more ways connecting to it, and that the weird ones are degenerate cases. It seems rather subject to editor rot: though that's the problem with all relations of course. You cannot determine the location of the ASL itself with your scheme, which is a bit of an oversight for a geographic database. Additionally it does not say what sort of traffic the advanced stop line is for. I think for it to be fully useful it would need to state both. Still, I'm not averse to relations provided they build on simpler elements which are easier for newbies to add, and are *only* deployed to resolve cases of ambiguity. I think there's likely to be very little ambiguity in practice; my gut feeling is that simple tagging of locations would be capable of expressing the vast majority of cases unambiguously. Counterexamples welcome, of course! At this early stage we get to stipulate that there either MUST[1] or SHOULD[1] be a highway=stop line "nearby, as part of the same way", and that both nodes must occur on one, and only one way. Would that be a workable approach? Do situations like ---stop-[hugegap]---asl---junc---stop- ever occur in practice? I note that even this ambiguity can be resolved by breaking the way at the junction node. [1] ... see RFC 2119 ... -- Andrew Chadwick ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
2012/5/23 Andrew Chadwick (lists) : > On 23/05/12 10:52, Gregory Williams wrote: >> There's also http://taginfo.openstreetmap.org/tags/type=advanced_stop_line >> which uses a relation containing the way approaching the ASL and the node of >> the junction of the ASL. With this method it's easier to determine the >> direction of approach to the ASL than just tagging a single node alone. > Thanks for the reminder; we'll have to organise those too. I'm not sure > they're completely consistent: Before using a relation only for asl's, please think of the proposed junction relation [1]. Maybe if the asl's are just put there, we don't need a separate relation. cheers, Martin [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Junctions ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
2012/5/23 Martin Koppenhoefer : > 2012/5/23 Martin Vonwald : >> Let's have a look at a street around here: it has two general lanes, >> one cycle lane and two side walks. I should map this with: >> * one way is "main" way >> * two ways for the lanes >> * one way for the cycle lane >> * two ways for the side walk >> * one relation >> So this gives me seven ways and one relation just for one street. > First of all: it is not "just for one street", it is 5 "lanes". It still is "just one street" - with five "lanes" ;-) > Suggestion (for the same street), high level of detail (i.e. I would > use this only for special cases, not for the average road without > irregularities): > > So I end up with 4 ways (highway, 2 sidewalks, cyclelane), one > relation (area) and some nodes (lowered kerbs). Of course this is more > complex, but you also get a whole lot more of detail, I see it the other way around: the increase in complexity does not justify the increase in detail. > especially if > there is more stuff to take into account (geometry not perfectly > parallel, barriers which are (partially) between the sidewalk and the > road, ability to map barriers on the sidewalk only, etc. If one would allow to change the width of the xway-parts, you could map geometry that is not perfectly parallel. > You will not map every street with this detail I guess, but you could > do it for situations that are complex in the real world. See - that's the main problem of this approach. It is much too complex for the common situations, so we should only use it in complex situations. And this will lead to a continuous switch between this approach and "standard" mapping. Imagine that: every now and then a simple road, specified by one way with some tags, magically changes to four, five, (how many was it) ways and a relation and just a few meters further collapses back to a single way. Do you think, that this is understandable? Maintainable? A solution that doesn't cover both - simple and complex - will fail IMO. Another possibility would be a solution, that seamless extends the simple case to the complex. The area-relation is missing this "seamlessness". > Doing it with > tags instead of dedicated geometry would in most (complex) cases > result in much less readable map data than explicit geometry (IMHO). I agree on this. I just question this particular geometry approach. >> If I >> want to move the "street" I have to move seven ways. > why would you want to move a street that you have surveyed up to this > level of detail? I think this is hypothetical (and btw: it is 6 in > your example). Japan moved a few meters not so long ago. >> If I want to add >> a junction I have to add a node to every way. > Yes, (see above, really not likely that you map a street with 5 ways > in every detail and then you discover that you "forgot" a whole > junction). I didn't forget the junction - it was just built. Facts changes! > Of course the junction will be more complex to map compared > to a simple node, but this is also one of the reasons you are doing > it: to get more details how the junction looks like. >> If the connecting road >> is also represented by seven ways I would have to connect... no, I >> don't count now... a lot of ways. > actually you would have to connect only those ways that are > intersecting in reality, not all of them (see above). I know, but this is still "a lot" compared to "one". >> Now I want to add a route relation for a bicycle route. For this I >> have to split the "street". > not at all, you will have the cyclelane where you put the relation to > and you will _not_ have to split the street. Then I misunderstood the proposal. That would be good. >> I have to split all seven ways, even if >> the bicycle route only refers to the bicycle lane. Excuse me, I'll >> stop right here. > I don't understand you here, can you explain this? Same as above. I erroneously assumed a statement which is valid for steps should also apply to other areas. >> BTW: >>> you will not get the support of who is interested >>> in the details of shape. >> If one would allow to change the width of each part at each node of >> the xway, you could quite nicely cover the shape of many features. > how would you know how to interpolate between two widths? It could be > a sharp corner or a smooth change. (almost) every corner at every > intersection is rounded. Will we split every x-way in y parts at any > of these points? Won't it be very difficult to get the center and > widths right in the case that the change of width is all on one side > of the street surface while the other keeps going straight? (This is > almost always the case btw.). The way I think about it, it would be quite simple: just draw the ways/lanes/barriers/whatever as they are, but they magically glue together and the width of each part is automatically determined. Don't ask me about details! I figured this out just a few hours ago. > Cheers, > Martin Same, Also
Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
On 23/05/12 10:52, Gregory Williams wrote: > There's also http://taginfo.openstreetmap.org/tags/type=advanced_stop_line > which uses a relation containing the way approaching the ASL and the node of > the junction of the ASL. With this method it's easier to determine the > direction of approach to the ASL than just tagging a single node alone. Thanks for the reminder; we'll have to organise those too. I'm not sure they're completely consistent: http://www.openstreetmap.org/browse/relation/75707 - 3 ways, all connecting to a central node http://www.openstreetmap.org/browse/relation/87140 - 2 ways, 1 node; ways are in sequence, node is *not* part of one http://www.openstreetmap.org/browse/relation/106889 - two 2-way sequences, 1 node, 1 plain way: 6 members http://www.openstreetmap.org/browse/relation/106868 - 7 ways all in a line, 1 node http://www.openstreetmap.org/browse/relation/158262 - 1 way http://www.openstreetmap.org/browse/relation/185408 - 1 node http://www.openstreetmap.org/browse/relation/239790 I assume the model was for 1 node and 1 or more ways connecting to it, and that the weird ones are degenerate cases. It seems rather subject to editor rot: though that's the problem with all relations of course. You cannot determine the location of the ASL itself with your scheme, which is a bit of an oversight for a geographic database. Additionally it does not say what sort of traffic the advanced stop line is for. I think for it to be fully useful it would need to state both. Still, I'm not averse to relations provided they build on simpler elements which are easier for newbies to add, and are *only* deployed to resolve cases of ambiguity. I think there's likely to be very little ambiguity in practice; my gut feeling is that simple tagging of locations would be capable of expressing the vast majority of cases unambiguously. Counterexamples welcome, of course! At this early stage we get to stipulate that there either MUST[1] or SHOULD[1] be a highway=stop line "nearby, as part of the same way", and that both nodes must occur on one, and only one way. Would that be a workable approach? Do situations like ---stop-[hugegap]---asl---junc---stop- ever occur in practice? I note that even this ambiguity can be resolved by breaking the way at the junction node. [1] ... see RFC 2119 ... -- Andrew Chadwick ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Geology and landcover - Building an extension
2012/5/23 Martin Koppenhoefer > 2012/5/23 sabas88 : > > What about building a proposal to extend landcover=* tag to meet FAO's > > system? > > > I think if you wanted to implement the FAO system you would need more > than one additional tag, so I suggest to make up a whole new proposal > to do this. Maybe you should also check if the FAO system is available > (copyright/licensing). Besides these problems I am in favour of the > FAO system, it seems well thought out. > Regarding the software, here [0] states the non-commercial clause. Should this proposal require prior authorization by FAO offices? [0]http://www.fao.org/docrep/008/y7220e/y7220e00.htm > > cheers, > Martin > > ___ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
Am 23.05.2012 10:32, schrieb Martin Koppenhoefer: 2012/5/23 Martin Vonwald: * two ways for the sidewalk (if you like, mapped at the outside of the sidewalk so it can be used to generate easily the area of the street) -1 for the parantheses: mapping the sidewalk "way" at one side of the sidewalk changes the meaning of the location of the way, and data consumers have to distinct between "this way is a "normal" way, abstracted to a center line" and "this way is a sidewalk, which can be seen probably because it's part of a street relation. Then let's calculate, where the main street way is according to this way to decide, which side the footway has to be rendered toward." - sorry, that sounds like crap. regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...?
There's also http://taginfo.openstreetmap.org/tags/type=advanced_stop_line which uses a relation containing the way approaching the ASL and the node of the junction of the ASL. With this method it's easier to determine the direction of approach to the ASL than just tagging a single node alone. Gregory -Original Message- From: Andrew Chadwick (lists) [mailto:a.t.chadwick+li...@gmail.com] Sent: 22 May 2012 11:42 To: Tag discussion, strategy and related tools Subject: [Tagging] Merge cycleway=asl/advanced_stop_line/bike_box/...? Can I gauge everyone's opinion on the following? We currently have four ways of representing a http://en.wikipedia.org/wiki/Advanced_stop_line namely, https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dasl https://wiki.openstreetmap.org/wiki/Tag:cycleway=bike_box http://taginfo.openstreetmap.org/tags/cycleway=advanced_stop http://taginfo.openstreetmap.org/tags/cycleway=advanced_stop_line (and maybe others?) These should probably be merged into one tag because they all refer to the same thing. There aren't very many of them in OSM right now, but from personal experience they're exceedingly common things in UK towns and cities. We can pick and choose the tag a little right now, given that it's not very well established. Let's not go with "asl"; abbreviations are generally bad practice. "advanced_stop_line" is bulky. "bike_box" is an Americanism, previously unknown to me. Personally, I like "cycleway=advanced_stop": it captures the forward position on the thing and the fact that it's a stop line, like the well established "highway=stop". Avoiding use of the terms "line" or "box" avoids concentrating too much on the physical form of the thing. I suppose it could be used with railway=* for trams, busway=* for buses and so on. Any other suggestions? -- Andrew Chadwick ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Geology and landcover - Building an extension
2012/5/23 sabas88 : > What about building a proposal to extend landcover=* tag to meet FAO's > system? I think if you wanted to implement the FAO system you would need more than one additional tag, so I suggest to make up a whole new proposal to do this. Maybe you should also check if the FAO system is available (copyright/licensing). Besides these problems I am in favour of the FAO system, it seems well thought out. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
2012/5/23 Richard Mann : > Now if we had an editor that displayed some parallel lines if you put in > cycleway=track, and maybe something similar on the standard rendering... A > fancy renderer might take further tags about the degree and nature of > separation into account, perhaps even interpolating between values on nodes. > That's all entirely extensible. I don't think that storing interpolation and angles in tags is a good idea. You do not need _one_ editor in order to keep the data intact, you would need _all_ of them to support this, or at least all that allow to modify streets. > A botched > lets-just-put-it-all-in-a-relation-and-hope-someone-writes-an-algorithm-to-decipher-it > is probably just creating data, and destroying information. I think that this is a misconception, because it would all be on dedicated geometry, not in the relation. In the relation you could put (optionally) detail information like the height of the kerb (or more generally the nature of what is between the ways) or which ways are linearily connected, what we mostly don't collect at all for the moment. For many applications it would also be OK to not evaluate the relation at all and still you would get all information that is needed (because the highway-center line is kept). On the other hand you would get (if you wanted) the information, that you can cross the street there even if someone has mapped the sidewalk explicitly (something people are already doing, and which is actually destroying some information). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
On Wed, May 23, 2012 at 8:39 AM, Martin Vonwald wrote: > You have to keep in mind that most of the streets are in fact a > collection of parallel features. Only at some points (junctions, ends) > this might not be true. The proposed relation might(!) be a solution > for some special cases (e.g. irregular steps), but for the rest this > is unmanageable imo. Any solution should concentrate on the common and > make it simple, but also allow to handle the exceptions - maybe with > some extra effort. This proposed solution seems to concentrate on the > exceptions. > > > +1. Streets are predominantly 1-d objects. Computers are a lot better at unpacking stuff than repacking. Yes you can write intelligent algorithms to do it (at least, I begin to see how you might do it...), but the dataset's big enough as it is, without removing a bunch of useful constraints. Now if we had an editor that displayed some parallel lines if you put in cycleway=track, and maybe something similar on the standard rendering... A fancy renderer might take further tags about the degree and nature of separation into account, perhaps even interpolating between values on nodes. That's all entirely extensible. A botched lets-just-put-it-all-in-a-relation-and-hope-someone-writes-an-algorithm-to-decipher-it is probably just creating data, and destroying information. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
2012/5/23 Martin Vonwald : > Let's have a look at a street around here: it has two general lanes, > one cycle lane and two side walks. I should map this with: > * one way is "main" way > * two ways for the lanes > * one way for the cycle lane > * two ways for the side walk > * one relation > So this gives me seven ways and one relation just for one street. First of all: it is not "just for one street", it is 5 "lanes". If there are houses on the street, you will get more mays for instance. And more nodes for housenumbers, telephone booths, post boxes and so on. Obviously more detail will result in more data. Secondly I guess this would be the maximum you could do for a simple street like this (plus maybe some areas ;-) ). I would not map it like this even when using the proposed area relation. Suggestion (for the same street), high level of detail (i.e. I would use this only for special cases, not for the average road without irregularities): * one way (highway at the center) like it is now. From your description there does not seem to be any advantage of mapping the two lanes explicitly. * two ways for the sidewalk (if you like, mapped at the outside of the sidewalk so it can be used to generate easily the area of the street) * one way for the cycle lane (if you like) * nodes (or short ways) for the lowered kerbs * one relation (area) to connect sidewalks and road and kerbs (you would define the general kerb with tags in the relation and add the lowered_kerbs geometry as exception to the relation). So I end up with 4 ways (highway, 2 sidewalks, cyclelane), one relation (area) and some nodes (lowered kerbs). Of course this is more complex, but you also get a whole lot more of detail, especially if there is more stuff to take into account (geometry not perfectly parallel, barriers which are (partially) between the sidewalk and the road, ability to map barriers on the sidewalk only, etc. You will not map every street with this detail I guess, but you could do it for situations that are complex in the real world. Doing it with tags instead of dedicated geometry would in most (complex) cases result in much less readable map data than explicit geometry (IMHO). > If I > want to move the "street" I have to move seven ways. why would you want to move a street that you have surveyed up to this level of detail? I think this is hypothetical (and btw: it is 6 in your example). > If I want to add > a junction I have to add a node to every way. Yes, (see above, really not likely that you map a street with 5 ways in every detail and then you discover that you "forgot" a whole junction). Of course the junction will be more complex to map compared to a simple node, but this is also one of the reasons you are doing it: to get more details how the junction looks like. > If the connecting road > is also represented by seven ways I would have to connect... no, I > don't count now... a lot of ways. actually you would have to connect only those ways that are intersecting in reality, not all of them (see above). > Now I want to add a route relation for a bicycle route. For this I > have to split the "street". not at all, you will have the cyclelane where you put the relation to and you will _not_ have to split the street. This is one of the big advantages. In the other model you will have to split the street (cars) also for any change of attributes on any of the ways (sidewalks, cyclelane, ...), resulting in very fragmented roads (the more detail you add the more the center road gets fragmented), while this will be reduced a lot by having dedicated geometry to put the attributes to where they belong to. > I have to split all seven ways, even if > the bicycle route only refers to the bicycle lane. Excuse me, I'll > stop right here. I don't understand you here, can you explain this? > BTW: >> you will not get the support of who is interested >> in the details of shape. > If one would allow to change the width of each part at each node of > the xway, you could quite nicely cover the shape of many features. how would you know how to interpolate between two widths? It could be a sharp corner or a smooth change. (almost) every corner at every intersection is rounded. Will we split every x-way in y parts at any of these points? Won't it be very difficult to get the center and widths right in the case that the change of width is all on one side of the street surface while the other keeps going straight? (This is almost always the case btw.). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal
2012/5/22 Martin Koppenhoefer : > 2012/5/22 Martin Vonwald : >> What is needed (IMO!) is some >> kind of way (lets call it xway), that may consist of parts. Those >> parts run by default parallel and may only be moved nearer to/farther >> away from the center of the xway. Then you apply tags... > if you introduce this kind of abstraction (as real street parts are > not always parallel) you will not get the support of who is interested > in the details of shape. Let's have a look at a street around here: it has two general lanes, one cycle lane and two side walks. I should map this with: * one way is "main" way * two ways for the lanes * one way for the cycle lane * two ways for the side walk * one relation So this gives me seven ways and one relation just for one street. If I want to move the "street" I have to move seven ways. If I want to add a junction I have to add a node to every way. If the connecting road is also represented by seven ways I would have to connect... no, I don't count now... a lot of ways. Now I want to add a route relation for a bicycle route. For this I have to split the "street". I have to split all seven ways, even if the bicycle route only refers to the bicycle lane. Excuse me, I'll stop right here. You have to keep in mind that most of the streets are in fact a collection of parallel features. Only at some points (junctions, ends) this might not be true. The proposed relation might(!) be a solution for some special cases (e.g. irregular steps), but for the rest this is unmanageable imo. Any solution should concentrate on the common and make it simple, but also allow to handle the exceptions - maybe with some extra effort. This proposed solution seems to concentrate on the exceptions. BTW: > you will not get the support of who is interested > in the details of shape. If one would allow to change the width of each part at each node of the xway, you could quite nicely cover the shape of many features. If for example some kind of barrier between one general lane the the side walk widens, simply increase the width of the barrier-part. Just my 0.02€ Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
