[OSM-talk] Gates (was: The Return of the Highway tags and other junk)

Mon Dec 18 22:09:10 GMT 2006

So you're deliberately ignoring a common standard, because you don't
like the level of abstraction?
That's not really the best way to do it, since that might make your data
invalid. the sheer amount of data needs a formal way of managing it, so
adhering to the standard is key there.
Well I don't care as long as you keep it compatible (a segment tagged
gate crossing a road, plus a node in the road that is tagged as gate)
and thoroughly document what you're doing, unless you plan to keep
maintaining this data for the next 10-20 years at the least.

> Guy:
> 
>> I have to agree with Andy and Dirk here, as you could by not staying with 
>> the agreed tagging structures find that work hard work is destroyed either 
>> by someone indadvertantly deleating it as they updated the map or by an 
>> automated filter purging the dataset of unreognised tags.
> 
> In that case, I shall stay doing it as segments, as I have done this many 
> hundreds of times (est. 500).  The area I edit currently has knowbody else 
> for about 40 miles, So confrontation is yet to be a consern.   Ideally I 
> would like it never to be.   The reason here for staying with nodes seems to 
> be cause its easier, not cause its better.  That doesnt stand up to any 
> scutany I'm affirad.

I'm afraid I don't understand your last sentence there. You didn't at
all convince me, that what you accomplish by creating segments for gates
cannot be done by appropriately tagging and connecting the node.

>> I also agree with Dirk that we are mapping the the planet so that it can be 
>> navigated
> 
> Yes, I agree mostly, although actually we are making map data that can be 
> used for anything, and how anybody wishes.

Yes that's true. But the key point is, we are all working on the same
map. Which automatically generates the need for a standard how to do
certain things.

>> not making a scale drawing so that we can recreate it.
> 
> A map is a to scale drawing.  If a person wants to recrete it in a 3d 
> engine, then nothing should stop them.

To keep to the example of the gates: I can't imagine how a correctly
placed node, as intersection between fence and road, cannot be tagged
such, that a program can automatically generate the right imaging from
it, without the need of a segment for the actual gate.

>> Coming back to gates and cattle grids, these cannot be represented by 
>> anything else but a node if they are to be used by navigation software 
>> reading the way as they exist as the intersection of two features such as a 
>> fence crossing a road.
> 
> Yes I agree that the node has to be connected to the road, so that it can be 
> read the by navagation softwere.  This doesnt mean the segments cannot also 
> be there.  Its not just navagation softwere that will use maps.  People do 
> to, and im shore theres other reasons.

As I said I can't see your point, you say you need the segments to
accurately represent the gates, and I say you can put that information
in a tag easily, the direction it's opening, (the same direction as the
crossing way or against) the width, even the height if you want to put
it there. A renderer can easily mark this up and "push back" the
rendering of the fence so it doesn't get rendered over the space the
gate occupies.
For orientation (foot, car, bike), if the map contains all the gates on
a way and I know I have to turn right at the third gate what do I care
if it's a green wooden one or white metal (slightly derelict)? even more
so because that status could change. What happens to your gates in 20
years, do you know? Will you be there to update the data?

>> Thus if the fence crosses a road with a cattle grid and you make the cattle 
>> grid the correct width and in the fence the road won't see it and vice 
>> versa, either that or you ahve to have a single node at the crossing point 
>> as you do now with four short segments radiating from it each with the tag 
>> "cattle_grid=yes".
> 
> Yep.  As said in a previous message I tag the node that the road and gate 
> conenct to so the softwear can pick it up.

so you have

segment(fence)-node()-segment(gate)-node(gate)-segment(gate)-node()-segment(fence)

and on the road: segment(road)-node(gate)-segment(road) ?

the "node(gate)" is the intersection between the two, the () indicate
tagging/membership of a way tagged in that way.

>> quickest and simplest method of recording and rendering it.
> 
> Its also quickest to make the M1 1 segment long, and have a straight line 
> the entire way.  The quickest way has nothing to do with what is the best 
> way.  Its quality not quantity here.   If 2 methods give the same outcome 
> and 1 is quicker then thats different, but this is not an example of that.  
> 1 node gives less information than a segment, and is contradictory to 
> reality and mapping in general.

The quickest way and still be accurate within the resolution of OSM. And
I'm still convinced you won't lose any information by just using nodes.

>> When recording gates and cattle grids in features that run parallel to 
>> roads you will obviously have to create a short track off the road and then 
>> place the gate/grid node on that rather than on the road itself.
> 
> If you mean where roads split into a grid and gate, along gated roads, then 
> the road needs to be split anyway, so I don't understand the problem with 
> that.

We seem to have quite different viewpoints on how data gets turned into
information. You seem to underestimate the value of context in that
process. You can leave out data, if the context provides enough
additional data to make it an information.

> I'm sorry, but I havn't heard 1 point that would make a node seem the 
> logical thing to do.  I have been mapping these feautres for almost a year, 
> and this is what Ive come to evaluate as the most succesfful method of 
> recording data.  I would be interested to know the amount of research that 
> has gone into debating the idea of sticking them as nodes.  I will stand 
> corrected if proven wrong, but this really isn't gunna happen at the moment. 
>   These points don't seem to stand up to much scrutany. In short If there 
> isnt some rasional agreement, I will just ignore it.

"I've always done it that way" is not really an argument towards either
side of the discussion.

Point is, both methods work, and I'm arguing that they work equally well
for the result that comes out of it, and therefore the node solution is
better, because it is simpler.

> Guy: For your second post check the 'Ben's bridge reply'.  There is probably 
> faults with it that I would currently alter, but correct on finding, but in 
> gerneral route finding should be able to find its way threw that combination 
> I think.
> 
> Pictorial accuracy in maps is as inportant as the datas posible use for auto 
> route finding.  Not everyone uses routefinders and maps togheter all the 
> time.

That is a problem of the renderer, not the data. Again you seem to
confuse data with information. However it is necessary to provide hints
to automatic renderers so it gives sensible results. I haven't looked at
your bridge in JOSM, so I can't tell wether it's a hint to the renderer,
or a hindrance to routeplanning. Since you seem to try to be compatible
to the simpler (in your eyes perhaps too simple) "osm standard" I'm
assuming the former.

Dirk-Lüder "Deelkar" Kreie

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFhxGFFUbODdpRVDwRAtZ3AJ46GZLbg7jZ/R2upRjV6Z1VWXv3hACgrS1b
CF4aYRd71LT9amWRya+lOe0=
=ehK3
-----END PGP SIGNATURE-----