On 1 February 2010 03:34, Anthony wrote:
> Just watched http://www.vimeo.com/5673183
>
> Yeah, ultimately we're going to need to use areas with elevation information
> and/or full blown polyhedra. Yes, 2D mapping isn't sufficient. But 2D is
> closer to 3D than 1D. :)
We're already doing quasi
On Mon, Feb 1, 2010 at 11:38 AM, John Smith 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
On 1 February 2010 11:59, Roy Wallace 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 are
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/listi
On Mon, Feb 1, 2010 at 12:07 PM, John Smith wrote:
> On 1 February 2010 11:59, Roy Wallace 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 de
...@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
Date: Mon, 1 Feb 2010 12:10:59
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Micro Ma
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).
On Sun, Jan 31, 2010 at 8:38 PM, John Smith 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 ma
On 1 February 2010 12:53, Richard Welty 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
On 1 February 2010 13:19, Anthony 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
John Smith
> Date: Mon, 1 Feb 2010 12:10:59
> To: Tag discussion, strategy and related tools
> 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 e
On 1 February 2010 12:42, John F. Eldredge 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,
On 1 February 2010 12:37, Roy Wallace 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
On 1 February 2010 12:37, Roy Wallace 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 st
On Sun, Jan 31, 2010 at 10:28 PM, John Smith wrote:
> On 1 February 2010 13:19, Anthony 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 an
On 1 February 2010 13:38, Anthony 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 happ
On Sun, Jan 31, 2010 at 10:46 PM, John Smith wrote:
> On 1 February 2010 13:38, Anthony 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 edito
On Mon, Feb 1, 2010 at 1:28 PM, John Smith 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 speakin
On 1 February 2010 14:21, Roy Wallace 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 spee
On Mon, Feb 1, 2010 at 3:26 PM, John Smith wrote:
> On 1 February 2010 14:21, Roy Wallace 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 descri
On Mon, Feb 1, 2010 at 12:26 AM, John Smith wrote:
> On 1 February 2010 14:21, Roy Wallace 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 d
On Mon, Feb 1, 2010 at 12:50 AM, Roy Wallace 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=
On Mon, Feb 1, 2010 at 3:53 PM, Anthony 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@o
On 1 February 2010 17:09, Roy Wallace 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@o
On 1 February 2010 15:50, Roy Wallace 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 t
On 1 February 2010 13:19, Anthony wrote:
> Now, I'm all about real world examples, so here's one:
> http://maps.google.com/?ll=28.083511,-82.505397&spn=0.000721,0.001155&z=20
>
> Take a look at the Northbound traffic. You have three main lanes of
> traffic, two left turning lanes on the left, and
On Mon, Feb 1, 2010 at 2:55 AM, John Smith wrote:
> What's to stop us tagging the node reference with a width?
>
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.
___
On 2 February 2010 00:27, Anthony 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
On 1 February 2010 13:31, Anthony 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 s
On Tue, Feb 2, 2010 at 4:59 AM, John Smith wrote:
> On 1 February 2010 13:31, Anthony 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.
>
>
On 3 February 2010 10:26, Anthony 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
On Mon, Feb 1, 2010 at 3:21 PM, Roy Wallace 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 so
On 1 February 2010 17:55, John Smith wrote:
> I just remembered, that nodes attached to ways have the following XML
>
>
>
>
>
>
> What's to stop us tagging the node reference with a width?
>
>
>
>
>
>
> This is tagging the way, but at the node references.
I let this go a c
On 3 February 2010 17:25, John Smith 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 t
Steve Bennett wrote:
> 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.
>
On Wed, Feb 3, 2010 at 5:25 PM, John Smith 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 ab
On Wed, Feb 3, 2010 at 5:28 PM, John Smith wrote:
>
>> ... tag nodes, but as it applies to
>> a way...
>
> 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.
I guess...but
On 4 February 2010 07:24, Roy Wallace 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 re
On 4 February 2010 07:22, Roy Wallace 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 (prob
On Thu, Feb 4, 2010 at 8:31 AM, John Smith wrote:
>
> On 4 February 2010 07:24, Roy Wallace 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 segm
On Thu, Feb 4, 2010 at 8:32 AM, John Smith wrote:
> On 4 February 2010 07:22, Roy Wallace 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 previou
On 4 February 2010 10:02, Roy Wallace 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 soluti
On 4 February 2010 10:04, Roy Wallace wrote:
> 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 :)
You had it correct based on the assumption
On Thu, Feb 4, 2010 at 11:55 AM, John Smith wrote:
>
> You had it correct based on the assumptions I've previously made, but
> the downside to that suggestion is when there is 2 lanes one way and 3
> the other, so the node would need 2 width values to compensate.
Again, no idea what you mean. Dia
On 4 February 2010 16:00, Roy Wallace wrote:
> Again, no idea what you mean. Diagram...?
Dunno if my diagram will make things better or not, I don't do well at
most forms of art.
http://wiki.openstreetmap.org/wiki/Vectorising_Way_Widths
The dots are nodes, the thick centre line is the way as we
On Thu, Feb 4, 2010 at 6:35 PM, John Smith wrote:
>
> The dots are nodes,
Got it.
> the thick centre line is the way
Got it.
> the medium thickness lines are where the nodes would be where the
> centre line is extended from/to
Huh?
> the thinner lines are lanes.
Huh? Do they exist in the da
On 4 February 2010 19:58, Roy Wallace wrote:
>> the medium thickness lines are where the nodes would be where the
>> centre line is extended from/to
>
> Huh?
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
g
On Thu, Feb 4, 2010 at 8:06 PM, John Smith 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
On Fri, Feb 5, 2010 at 7:13 AM, Roy Wallace wrote:
> On Thu, Feb 4, 2010 at 8:06 PM, John Smith 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
from a side
road; and outside lanes for slower traffic to use when climbing a long hill.
---Original Email---
Subject :Re: [Tagging] Micro Mapping, was Race track
>From :stevag...@gmail.com
Date :Thu Feb 04 18:00:27 America/Chicago 2010
Are there really that many asymmetric roads, with
On 5 February 2010 06:13, Roy Wallace 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, wh
51 matches
Mail list logo
