Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:06 PM, John Smith deltafoxtrot...@gmail.com wrote: Imagine a mechanism in your favourite editor when you can drag the width of the node outwards to match the width of the road, this then gets stored against the node information for the way. Ah ok. Hmm, I'd prefer that the OSM way is the centerline of the feature. This would mean: 1) the OSM way is consistently meaningful in itself, and matches current usage 2) you only have one width value per node, which might simplify editing. But it seems like you're suggesting that the OSM way instead should represent: a) if a oneway feature: the centerline b) if a twoway feature: the divider between traffic travelling in each direction Could work I guess... the thinner lines are lanes. Huh? Do they exist in the database? If so, as what? That's part of my goal with all this, to make them exist. way id='-1' visible='true' nd ref='-1' width='50' lanes:left='2' lanes:right='3' / nd ref='-2' width='40' lanes:left='2' lanes:right='2' / /way Or something to that effect. Ah now I see what you mean. Can you add all of the necessary tags to the example in your diagram? In particular: 1) please indicate the geometric interpretation of width='50' and width='40' 2) write out the lane tags next to each node. I think you'll quickly see that it's difficult to decide how many lanes:right the middle node has, i.e. 2 or 3? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Fri, Feb 5, 2010 at 7:13 AM, Roy Wallace waldo000...@gmail.com wrote: On Thu, Feb 4, 2010 at 8:06 PM, John Smith deltafoxtrot...@gmail.com wrote: Imagine a mechanism in your favourite editor when you can drag the width of the node outwards to match the width of the road, this then gets stored against the node information for the way. Ah ok. Hmm, I'd prefer that the OSM way is the centerline of the feature. This would mean: 1) the OSM way is consistently meaningful in itself, and matches current usage 2) you only have one width value per node, which might simplify editing. I think I'm inclined to agree. Any renderer that supports all these tags won't be particularly inconvenienced by the fact that the line isn't down the centreline, and any renderer that doesn't will do a better job of rendering it. That said, it would be fairly rare for the central divider to be far from the geometric centre of the road for a non-divided highway, wouldn't it? Are there really that many asymmetric roads, with say one lane on one direction, and two in the others (as in the diagram)? The biggest problem I see with John's proposal (as I understand it) is that it adds lane information not onto nodes, and not onto ways, but onto the *relationship* between ways and nodes. I could be misunderstanding it, as I'm not really familiar with the underlying data structure. And in any case, lane information is intuitively not a property of a node, but of a section between two nodes. This proposal would appear to make it very easy to make long sections of road where the number of lanes is changing - not particularly useful. In fact, I'm not sure it's even useful to be able to code that. But it seems like you're suggesting that the OSM way instead should represent: a) if a oneway feature: the centerline b) if a twoway feature: the divider between traffic travelling in each direction It does seem a bit inconsistent. A three lane one-way road will have the way running down the centre of the middle lane. A three lane two-way road will have it running between two lanes. Or, to put it differently, for a given way with lane tags, where a renderer should render the road will depend on the property of the oneway=* tag. Which is extremely counterintuitive. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 5 February 2010 06:13, Roy Wallace waldo000...@gmail.com wrote: But it seems like you're suggesting that the OSM way instead should represent: a) if a oneway feature: the centerline b) if a twoway feature: the divider between traffic travelling in each direction I already map the node at the centreline, which isn't nessicarily the same thing as the midle of the road, this is more likely to be somewhat accurate if you are driving along the lanes either side of the centre line, but since we don't have super accurate GPS units yet it won't be that apparent. way id='-1' visible='true' nd ref='-1' width='50' lanes:left='2' lanes:right='3' / nd ref='-2' width='40' lanes:left='2' lanes:right='2' / /way Ah now I see what you mean. Can you add all of the necessary tags to the example in your diagram? In particular: 1) please indicate the geometric interpretation of width='50' and width='40' 2) write out the lane tags next to each node. I think you'll quickly see that it's difficult to decide how many lanes:right the middle node has, i.e. 2 or 3? The example above was before I realised you'd need 2 widths to describe things properly in the case of asymmetric lanes. I also realise the description isn't the best way to do things but I'm having a hard time thinking of something better, although if we use the direction of the way we could just tag it left/right... However to describe the previous diagram in XML it might be something like this: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='-1' visible='true' lat='-0.17652801739620505' lon='-3.788568828743543' / node id='-2' visible='true' lat='1.1360435677193206' lon='-1.0003270145189043' / node id='-4' visible='true' lat='1.1179416038429335' lon='3.0009810435567132' / way id='-3' action='modify' visible='true' nd ref='-1' left lanes='1' width='5' / right lanes='1' width='5' / /nd nd ref='-2' left lanes='1' width='5' / right lanes='1' width='5' / /nd nd ref='-4' left lanes='2' width='10' / right lanes='1' width='5' / /nd /way /osm ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Wed, Feb 3, 2010 at 5:25 PM, John Smith deltafoxtrot...@gmail.com wrote: This is tagging the way, but at the node references. I let this go a couple of days to see if anyone would find any problems with doing this. It is one option for tagging width, but users would then still need to make some assumption about the direction in which width is measured (probably the bisection of the angle between previous/following nodes) and interpolate between nodes (probably linearly). It's also (at first glance) a very big change to the OSM data model. There may be other problems, but that's the main one I can think of. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 4 February 2010 07:24, Roy Wallace waldo000...@gmail.com wrote: I guess...but this might be tricky for editors to deal with when way direction is reversed. Not really, think of the bits between nodes as segments, you apply the information to a segment, except width which is applied at the specific point, the rest is just vector type informaiton. Also, a maxspeed conceptually applies to a way, not a node. This is therefore only worth doing if you really really want to avoid splitting ways. The problem at the present is ways get split for a lot of reasons, this may reduce the amount of splitting. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 4 February 2010 07:22, Roy Wallace waldo000...@gmail.com wrote: It is one option for tagging width, but users would then still need to make some assumption about the direction in which width is measured (probably the bisection of the angle between previous/following nodes) and interpolate between nodes (probably linearly). If you assume the node is the mid point of the way, width at that point is simply the width, and the width at the surrounding points is that width and the rest is just vector math. It's also (at first glance) a very big change to the OSM data model. There may be other problems, but that's the main one I can think of. Bigger than relations? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:31 AM, John Smith deltafoxtrot...@gmail.com wrote: On 4 February 2010 07:24, Roy Wallace waldo000...@gmail.com wrote: I guess...but this might be tricky for editors to deal with when way direction is reversed. Not really, think of the bits between nodes as segments, you apply the information to a segment, except width which is applied at the specific point, the rest is just vector type informaiton. Upon reversal of the way, editors would have to automatically convert [1] to [2]. http://www.myimgs.net/images/lmwa.gif http://www.myimgs.net/images/mjrp.gif Still feasible, but it is worth noting. Also, a maxspeed conceptually applies to a way, not a node. This is therefore only worth doing if you really really want to avoid splitting ways. The problem at the present is ways get split for a lot of reasons, this may reduce the amount of splitting. I know. But if you are happy with splitting (as I am), then the current solution is fine. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Thu, Feb 4, 2010 at 8:32 AM, John Smith deltafoxtrot...@gmail.com wrote: On 4 February 2010 07:22, Roy Wallace waldo000...@gmail.com wrote: It is one option for tagging width, but users would then still need to make some assumption about the direction in which width is measured (probably the bisection of the angle between previous/following nodes) and interpolate between nodes (probably linearly). If you assume the node is the mid point of the way, width at that point is simply the width, and the width at the surrounding points is that width and the rest is just vector math. I have no idea what you're talking about. This is my interpretation of your idea, as it stands: http://www.myimgs.net/images/plxo.gif If I've got the wrong idea, please draw a diagram of what you mean :) It's also (at first glance) a very big change to the OSM data model. There may be other problems, but that's the main one I can think of. Bigger than relations? No idea. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 4 February 2010 10:02, Roy Wallace waldo000...@gmail.com wrote: Still feasible, but it is worth noting. This already happens in JOSM with ways when they are oneway=yes... slightly different, but there is already triggers for it... I know. But if you are happy with splitting (as I am), then the current solution is fine. I'm indifferent, others have noted in the past they would prefer ways not to be split, I'm just pointing out this is possible. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 13:31, Anthony o...@inbox.org wrote: that altitude error will always be worse than lat/lon error. But I think that's a good argument for not recording absolute elevation but rather recording some sort of relative elevation. The reason for absolute elevation is simply because most GPS software isn't capable of differentiating between relative layers, although now that I think about it some more, from a programming point of view this seems it should only be an issue until the GPS figured out which layer you are currently driving on. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Tue, Feb 2, 2010 at 4:59 AM, John Smith deltafoxtrot...@gmail.comwrote: On 1 February 2010 13:31, Anthony o...@inbox.org wrote: that altitude error will always be worse than lat/lon error. But I think that's a good argument for not recording absolute elevation but rather recording some sort of relative elevation. The reason for absolute elevation is simply because most GPS software isn't capable of differentiating between relative layers, although now that I think about it some more, from a programming point of view this seems it should only be an issue until the GPS figured out which layer you are currently driving on. I'm not sure what GPS software you're talking about. For recording of altitudes, I'm not sure GPS is not accurate enough to be very useful. Also, there's the issue of what vertical datum is being used. For most GPSes it is easy to set the datum for the lat/lon to WGS84, but the vertical datums vary quite a bit, they're often hard to determine, and in many cases they can't be changed. On the other hand, it's pretty easy to find out the height of an overpass, and/or estimate it (by photographs, by memory, or even by triangulation using free apps available on some smart phones). Therefore, I believe these two measurements should be stored separately. We know that overpass A passes 6 meters over road B, within say 1/3 of a meter. Whereas we know that road B is at 10 meters above sea level, with respect to NAVD83, within say 4 meters (which is a reasonable vertical GPS error bound). If we had measured the roads separately and given them absolute elevations, we might be off by 4 meters on overpass A, and 4 meters in the opposite direction on road B, and not even know which one is above the other. And then when we drive on the road our GPS readings might be off by another 4 meters. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 3 February 2010 10:26, Anthony o...@inbox.org wrote: I'm not sure what GPS software you're talking about. For recording of altitudes, I'm not sure GPS is not accurate enough to be very useful. Also, I already made that point. there's the issue of what vertical datum is being used. For most GPSes it is easy to set the datum for the lat/lon to WGS84, but the vertical datums vary quite a bit, they're often hard to determine, and in many cases they can't be changed. Can the elevation be set on any GPS units? I assumed anything without an altimiter would simply use GPS derived information. If we had measured the roads separately and given them absolute elevations, we might be off by 4 meters on overpass A, and 4 meters in the opposite direction on road B, and not even know which one is above the other. And then when we drive on the road our GPS readings might be off by another 4 meters. Errors are irrelevent, as long as point A is than point B you can guess which one is higher than the other. The point is giving GPS devices help, when said GPS devices are capable of knowing where they are elevation wise, to know which layer they are on, relative information won't help unless they already know which way they are located on. Think of the Japanese situation where there is multiple decks, how does the GPS know which one the user is travelling on to tell them the correct speed limit for example. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 3:21 PM, Roy Wallace waldo000...@gmail.com wrote: Think about it: 1) use tags on nodes to describe an area 2) use an area to describe an area IMHO, the right solution will almost certainly allow both. Just as there are a wide range of users inputting data that comes from a wide range of sources, we should be flexible and accommodate this. Essentially your options are: 1) Computed areas 2) Measured areas If we have access to accurate measurements of areas, then yes, we should store them. If we don't, then computations (based on width, or number of lanes, or whatever) are much better than nothing. Btw... what the hell was the big discussion about scrambled GPS signals for altitudes about? Way off topic. This list really needs a moderator. Between the three of you you manage to create like a hundred messages of spam in two days, yet say virtually nothing. Why don't you use some other medium for this rapid fire exchange of half-arsed ideas and petty bickering, and post to the list when you have something substantial to say? It's completely ridiculous. Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 17:55, John Smith deltafoxtrot...@gmail.com wrote: I just remembered, that nodes attached to ways have the following XML way id='-7' visible='true' nd ref='-2' / nd ref='-6' / /way What's to stop us tagging the node reference with a width? way id='-1' visible='true' nd ref='-1' width='50' lanes:left='2' lanes:right='3' / nd ref='-2' width='40' lanes:left='2' lanes:right='2' / /way This is tagging the way, but at the node references. I let this go a couple of days to see if anyone would find any problems with doing this. What I've suggested above means we can tag nodes, but as it applies to a way, this would obviously need to be supported by editors etc, but solves the problem of one thing, one object as far as I can see. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 3 February 2010 17:25, John Smith deltafoxtrot...@gmail.com wrote: What I've suggested above means we can tag nodes, but as it applies to a way, this would obviously need to be supported by editors etc, but solves the problem of one thing, one object as far as I can see. It could also solve things like reducing the need to split a way for maxspeed changes, as you could tag a point where the speed changes in the direction of the arrows etc. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 2 February 2010 00:27, Anthony o...@inbox.org wrote: Lack of support in the software, which in turn is caused by lack of svn access, which in turn is caused by lack of an approved proposal. That isn't a valid answer, or relations wouldn't exist, either my suggestion is valid and we press to have software support those changes or it's not valid and we need a better solution. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 11:38 AM, John Smith deltafoxtrot...@gmail.com wrote: Going with Richards idea, what about making the editor do the grunt work, place a node at a point, and then have the editor calculate the width by stretching the road way side ways, then apply the width values against nodes, which would make areas redundent. Interesting, but what you're really doing (if i understand you correctly) is: 1) storing a way, plus 2) storing an approximate area (in the form of width tags applied to nodes on the way, and then using some form of interpolation between nodes). The alternative is: 1) storing a way, plus 2) storing an area ...and (optionally, but preferably) relating the two with e.g. type=area; role=center; role=area [1]. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 11:59, Roy Wallace waldo000...@gmail.com wrote: Interesting, but what you're really doing (if i understand you correctly) is: You missed the point on lanes then, which is mostly what I'm interested in, being able to plot lanes and then describing them. 1) storing a way, plus 2) storing an area How do you use an area to describe lanes and so forth? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
The only other problem left to solve is the 3D bit, elevation could be added to nodes as well, but all we need then is GPS equipment that has more accurate elevation. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 12:07 PM, John Smith deltafoxtrot...@gmail.com wrote: On 1 February 2010 11:59, Roy Wallace waldo000...@gmail.com wrote: Interesting, but what you're really doing (if i understand you correctly) is: You missed the point on lanes then, which is mostly what I'm interested in, being able to plot lanes and then describing them. I have no idea what you're talking about. Maybe it is best if you put together a proposal page so we can see all aspects of your idea(s) in one place... 1) storing a way, plus 2) storing an area How do you use an area to describe lanes and so forth? A lane could be described, geometrically, by an area (to indicate the space it takes up on the Earth's surface) and a way (to indicate the centerline and direction of travel). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
It may be difficult to obtain GPS equipment that has accurate altitude data. The GPS satellite system is maintained by the US military, and I have read that the altitude information available to civilian equipment has deliberate errors, in order to make it harder for terrorists, or non-US militaries, to use that equipment to plan out artillery attacks in advance. The equipment used by the US military makes use of a more accurate, but encrypted, altitude signal. In the US, at least, such equipment is classified and not legally available to civilians. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria -Original Message- From: John Smith deltafoxtrot...@gmail.com Date: Mon, 1 Feb 2010 12:10:59 To: Tag discussion, strategy and related toolstagging@openstreetmap.org Subject: Re: [Tagging] Micro Mapping, was Race track The only other problem left to solve is the 3D bit, elevation could be added to nodes as well, but all we need then is GPS equipment that has more accurate elevation. ___ 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] Micro Mapping, was Race track
On 1/31/10 8:59 PM, Roy Wallace wrote: Interesting, but what you're really doing (if i understand you correctly) is: 1) storing a way, plus 2) storing an approximate area (in the form of width tags applied to nodes on the way, and then using some form of interpolation between nodes). The alternative is: 1) storing a way, plus 2) storing an area ...and (optionally, but preferably) relating the two with e.g. type=area; role=center; role=area [1]. i've come around to way + area. long term handling of elevation is relevant to the race track problem, here's an elevation map of watkins glen to provide more than enough rationale: http://www.na-motorsports.com/Tracks/NY/images/glen/elev.gif ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Sun, Jan 31, 2010 at 8:38 PM, John Smith deltafoxtrot...@gmail.comwrote: Going with Richards idea, what about making the editor do the grunt work, place a node at a point, and then have the editor calculate the width by stretching the road way side ways, then apply the width values against nodes, which would make areas redundent. I've got no problem with letting the editor do the grunt work. But a way with a width is difficult to connect lengthwise to another way with a width, or to an area. If we also define the numbe of lanes on a per node basis we wouldn't need to split ways just because lanes increased or descreased. Way information should not be on nodes. What happens when someone connects a second way to the same node? Now they have to examine the node to check whether or not there are tags on it? No. Bad idea. --- Now, I'm all about real world examples, so here's one: http://maps.google.com/?ll=28.083511,-82.505397spn=0.000721,0.001155z=20 Take a look at the Northbound traffic. You have three main lanes of traffic, two left turning lanes on the left, and a right turning lane on the right. You also have an entrance/exit to a shopping area on the right. Now, good lane-based navigation software is going to let you know to get into (or avoid) the right hand turning lane well before the shopping area entrance. This is not a six lane road, it's a three lane road with three additional turning lanes. However, traffic exiting the shopping area is not limited to the right turning lane. It can certainly enter the three main lanes, and if you're feeling lucky (or if it's a low traffic time of the day), can even make it into the left turning lanes. This is a great case for mapping lanes, and it's a tricky one to get right. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 12:53, Richard Welty rwe...@averillpark.net wrote: long term handling of elevation is relevant to the race track problem, here's an elevation map of watkins glen to provide more than enough rationale: This isn't about race tracks any more, but complex mapping of road ways, especially those with multiple road way decks with even more complex on/off ramps ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
I've heard that before about GPS equipment, but I'm not convinced it a) is true; and b) isn't easy to workaround, even if true. The raw data received by a GPS is timing data. How can they mess up the altitude without messing up the lat and lon? And even if they can (presumably by lying about the altitude of the satellites?), can't some sort of DGPS, using known altitudes of fixed locations, be used to counteract the deliberate errors? Granted, I don't think GPS is ever going to be a good way to get precise altitude information. As I understand it this is a matter of geometry and that altitude error will always be worse than lat/lon error. But I think that's a good argument for not recording absolute elevation but rather recording some sort of relative elevation. http://www.na-motorsports.com/Tracks/NY/images/glen/elev.gif is a good example of relative elevation. Even if we just used a relation among the nodes making up the track that would be quite useful. We could go back later and find out a precise elevation for one point on the track to convert that to absolute elevation, but in the mean time relative elevation would be quite useful. On Sun, Jan 31, 2010 at 9:42 PM, John F. Eldredge j...@jfeldredge.comwrote: It may be difficult to obtain GPS equipment that has accurate altitude data. The GPS satellite system is maintained by the US military, and I have read that the altitude information available to civilian equipment has deliberate errors, in order to make it harder for terrorists, or non-US militaries, to use that equipment to plan out artillery attacks in advance. The equipment used by the US military makes use of a more accurate, but encrypted, altitude signal. In the US, at least, such equipment is classified and not legally available to civilians. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria -Original Message- From: John Smith deltafoxtrot...@gmail.com Date: Mon, 1 Feb 2010 12:10:59 To: Tag discussion, strategy and related toolstagging@openstreetmap.org Subject: Re: [Tagging] Micro Mapping, was Race track The only other problem left to solve is the 3D bit, elevation could be added to nodes as well, but all we need then is GPS equipment that has more accurate elevation. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ 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] Micro Mapping, was Race track
On 1 February 2010 12:42, John F. Eldredge j...@jfeldredge.com wrote: It may be difficult to obtain GPS equipment that has accurate altitude data. The GPS satellite system is maintained by the US military, and I have read that the altitude information available to civilian equipment has deliberate errors, in order to make it harder for terrorists, or non-US militaries, to use that equipment to plan out artillery attacks in advance. The equipment used by the US military makes use of a more accurate, but encrypted, altitude signal. In the US, at least, such equipment is classified and not legally available to civilians. Long term people will work out a way round the altitude problem if the need is great enough, just like they worked round the horizontal accuracy problem, even prior to SA being turned off people had a solution for over coming SA errors, which may have lead to SA being turned off earlier than originally planned. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 12:37, Roy Wallace waldo000...@gmail.com wrote: A lane could be described, geometrically, by an area (to indicate the space it takes up on the Earth's surface) and a way (to indicate the centerline and direction of travel). Vector data can do close approximations too, which is what an area is as well. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 12:37, Roy Wallace waldo000...@gmail.com wrote: I have no idea what you're talking about. Maybe it is best if you put together a proposal page so we can see all aspects of your idea(s) in one place... My thoughts on a solution have changed based on Richard's suggestion about using a node to store the information, it's better than what I was originally thinking, don't have time to do a wiki page till this evening, but that will give me some more time to ponder over things. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Sun, Jan 31, 2010 at 10:28 PM, John Smith deltafoxtrot...@gmail.comwrote: On 1 February 2010 13:19, Anthony o...@inbox.org wrote: I've got no problem with letting the editor do the grunt work. But a way with a width is difficult to connect lengthwise to another way with a width, or to an area. Why would it be any more difficult than using areas, if the editors display the data correctly then you can edit it correctly too. It's trivial with areas. If the borders touch, the areas touch. You can't do that using a way and a width, unless you expect to do a bunch of calculations behind the scenes (in the editors, in the routers, in the renderers, etc). Way information should not be on nodes. What happens when someone connects Nodes are the perfect point to do it, they are the 2D location, ways give you direction, nodes give you width. a second way to the same node? Now they have to examine the node to check whether or not there are tags on it? No. Bad idea. You are assuming we are using the same tools we are using now to do stuff, if the editors become smart enough to enter width information they can display it as well. I'm assuming the data is being put on the nodes, because that's the suggestion. Nodes can be shared by multiple ways. If you're saying that's not true, fine, but then you're not really talking about nodes any more. In the current system, this might be implemented using a relation between a node and a way - okay, fine, that would work, though it seems more kludgy than just mapping the left and right borders as ways, which gives you an implicit width, plus gives you hooks so you can do things like show that the right hand side of the road is directly adjacent (and routeable) to a particular pedestrian area (see the thread a while ago on how to connect pedestrian areas to ways, whether to lie about the pedestrian area, lie about the way, or add in a bunch of arbitrary connecting ways). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 13:38, Anthony o...@inbox.org wrote: It's trivial with areas. If the borders touch, the areas touch. You can't do that using a way and a width, unless you expect to do a bunch of calculations behind the scenes (in the editors, in the routers, in the renderers, etc). Which would happen with areas too, since we're dealing with vectors everything has to be calculated from points and extrapolated as to where the area should exist as a raster type image. I'm assuming the data is being put on the nodes, because that's the suggestion. Nodes can be shared by multiple ways. If you're saying that's I'm not sure what I'm saying yet. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Sun, Jan 31, 2010 at 10:46 PM, John Smith deltafoxtrot...@gmail.comwrote: On 1 February 2010 13:38, Anthony o...@inbox.org wrote: It's trivial with areas. If the borders touch, the areas touch. You can't do that using a way and a width, unless you expect to do a bunch of calculations behind the scenes (in the editors, in the routers, in the renderers, etc). Which would happen with areas too, since we're dealing with vectors everything has to be calculated from points and extrapolated as to where the area should exist as a raster type image. With areas, you'd share nodes (or, with areas formed with relations, share ways). For the problem, see http://www.openstreetmap.org/?lat=49.9461664259434lon=11.577060520649zoom=18 Luitpoldplatz should be connected to the pedestrian area adjacent to the west. But since Luitpoldplatz is represented as a way, and not an area, this is not possible without inaccurately mapping the way or the area. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 1:28 PM, John Smith deltafoxtrot...@gmail.com wrote: Why would it be any more difficult than using areas, if the editors display the data correctly then you can edit it correctly too. Think about it: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Nodes are the perfect point to do it, they are the 2D location, ways give you direction, nodes give you width. Erm no. You need to know along which direction the width is measured. You could *assume* that this is in the direction that bisects the angle between the previous and following nodes, but 1) this is an approximation and 2) this doesn't work if the node is connected to more than 2 other nodes. Thus... nodes are hardly the perfect point to indicate width. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 14:21, Roy Wallace waldo000...@gmail.com wrote: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Just like ways there is a lot of meta information to describe lanes, can you change lanes, do lanes have different speed limits, sure areas could be used for this, but the down side is you still need a way to describe the legal direction of travel, so the problem still exists an area alone doesn't describe everything. Erm no. You need to know along which direction the width is measured. A node is a point, the direction of width would be 90 degrees to the direction of travel. You could *assume* that this is in the direction that bisects the angle between the previous and following nodes, but 1) this is an approximation and 2) this doesn't work if the node is connected to Even areas are approximations, go look at river banks and tell me how many points are needed for an area, infinite is the correct answer anything less is an approximation. more than 2 other nodes. Thus... nodes are hardly the perfect point to indicate width. Neither are areas, they might approximate better but they still won't indicate width perfectly and they don't indicate direction of travel so we're still at square one, that is trying to describe a road, and the sub-objects, that is lanes etc. So the question still remains, how to describe a road way more accurately with a single object. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 3:26 PM, John Smith deltafoxtrot...@gmail.com wrote: On 1 February 2010 14:21, Roy Wallace waldo000...@gmail.com wrote: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Just like ways there is a lot of meta information to describe lanes, can you change lanes, do lanes have different speed limits, sure areas could be used for this, but the down side is you still need a way to describe the legal direction of travel, so the problem still exists an area alone doesn't describe everything. Indeed. Hence why I have said multiple times that I think a way PLUS an area is a better solution than trying to mangle the idea of an area into tags on nodes. Erm no. You need to know along which direction the width is measured. A node is a point, the direction of width would be 90 degrees to the direction of travel. See this drawing and tell me what the width tag means: http://www.myimgs.net/images/puan.gif So the question still remains, how to describe a road way more accurately with a single object. Why does it have to be a single object? A road has a centerline, and it has a footprint. Why not map both...? Here's a brainstorming picture, plenty of kinks to be worked out if anyone's up for a challenge: http://www.myimgs.net/images/psgb.gif E.g. if we're mapping ways as areas, how should the intersection area be tagged? Anyway, I'll now refrain from distracting you from writing up your proposal :) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 12:26 AM, John Smith deltafoxtrot...@gmail.comwrote: On 1 February 2010 14:21, Roy Wallace waldo000...@gmail.com wrote: 1) use tags on nodes to describe an area 2) use an area to describe an area Generally speaking, I predict 2) will be easier. Just like ways there is a lot of meta information to describe lanes, can you change lanes, do lanes have different speed limits, sure areas could be used for this, but the down side is you still need a way to describe the legal direction of travel, so the problem still exists an area alone doesn't describe everything. Not necessarily. A way is generally part of an area. Even if you used a single way, clockwise could represent one direction and counter-clockwise could represent the other direction. But for these areas relations would probably work better. Really, we should probably stop using the term area, as OSM doesn't have areas, it has nodes, ways, and relations. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 12:50 AM, Roy Wallace waldo000...@gmail.com wrote: Here's a brainstorming picture, plenty of kinks to be worked out if anyone's up for a challenge: http://www.myimgs.net/images/psgb.gif E.g. if we're mapping ways as areas, how should the intersection area be tagged? Instead of role=area, I'd suggest separate ways: role=left, role=right, and role=outer. The role=center way could then be optional, solely for backward compatibility. This way you can indicate direction directly on the relation. Plus you can share ways, so the role=left way for one lane (or set of lanes, or landuse area, or pedestrian area, or gore area, or barrier, etc.) can be the role=right way for another lane (or...). I set up a list of example situations to ponder at http://wiki.openstreetmap.org/wiki/User:%E2%A0%A0%E2%A0%81%E2%A0%9D%E2%A0%9E%E2%A0%93%E2%A0%95%E2%A0%9D%E2%A0%BD ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On Mon, Feb 1, 2010 at 3:53 PM, Anthony o...@inbox.org wrote: OSM doesn't have areas, it has nodes, ways, and relations. Area means a closed way, with tags referring to the entity bounded by the way. Simple enough I thought. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 17:09, Roy Wallace waldo000...@gmail.com wrote: Area means a closed way, with tags referring to the entity bounded by the way. Simple enough I thought. Polygon might be more applicable, area is a type of a polygon. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Micro Mapping, was Race track
On 1 February 2010 15:50, Roy Wallace waldo000...@gmail.com wrote: Indeed. Hence why I have said multiple times that I think a way PLUS an area is a better solution than trying to mangle the idea of an area into tags on nodes. What ever you call it, the problem is still the same, minimising the labour needed to describe something, that way more things can be drawn in the same or less amount of time. I still think it's a bad idea to be drawing 2 objects to describe a single idea, 1 object = 1 thing, in this case 2 objects = 1 thing. Twice the work (or more) but you don't get twice the benefit, the amount of information added is minimal. See this drawing and tell me what the width tag means: http://www.myimgs.net/images/puan.gif Sure, using nodes for complex information is meaningless, it was just an idea to reduce the amount of times a way needs to be split to describe something, using areas doesn't reduce the amount of data. Why does it have to be a single object? A road has a centerline, and it has a footprint. Why not map both...? That isn't the problem, all existing ways are made up on multiple objects to model increasingly complex things, however making mapping more complex doesn't increase the benefit at the same rate. Here's a brainstorming picture, plenty of kinks to be worked out if anyone's up for a challenge: http://www.myimgs.net/images/psgb.gif E.g. if we're mapping ways as areas, how should the intersection area be tagged? Anyway, I'll now refrain from distracting you from writing up your proposal :) I'm not the one insisting on it, in fact I'm still trying to encourage brain storming, but some people think things should be written up in a formal proposal before they'd ever consider thinking beyond their little box. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
