[Openstreetmap-dev] Data Primatives & schema

Matt Amos matt at matt-amos.uklinux.net
Wed Dec 21 14:04:21 GMT 2005

On Wednesday 21 December 2005 09:49, Andy Robinson wrote:
> Matt Amos wrote:
> >we have to be more explicit here, i think. the ways must consist
> > of an ordered list of segments, where two adjacent segments must
> > share one, but only one node and, apart from the first and last,
> > each node must be used precisely twice.
> That definition assumes that the order of the segments in line is
> 0, 1, 2 when it could be 356, 5669, 358 because a SEGMENT was
> deleted and a new one made. The only distinguishing attribute is
> the attached NODE uid's, should it be the NODE uid's that are used
> for the sequence making up a section of WAY?

yeah, my previous example had the nice feature that 0,1,2 were 
contiguous, which wasn't intentional. however, if 1 was deleted and 
new segment 321 was added with the same nodes it would also be valid. 
another example:

(segment number) => [ (first node number), second node number) )

0 => [0, 1)
321 => [1,101)
322 => [101,2)
2 => [2,3)

is valid, but

0 => [0, 1)
321 => [1,101)
2 => [2,3)

is not, because segments 321 and 2 are disjoint. also

0 => [0,1)
1 => [1,2)
321 => [1,101)

is not valid because the node with uid 1 is used 3 times (which means 
the way branches).

> I agree that ordering is required; however does the arrangement
> allow for breaks in the continuity of the WAY. This was an
> important and previously identified capability since many "street"
> ways are not contiguous over their complete length. In a client the
> user would select appropriate SEGMENTs but they may not be
> contiguous, so each section of WAY would presumably need to be
> similar to a gpx track segment where each are separate? Both may
> have the same name of course (eg Baker Street) but they each have a
> separate uid.

perhaps this is another concept, then? maybe there is an intermediate 
 - a segment is two distinct nodes
 - a line/polyline/whatever is a contiguous strip of segments with the 
rules stated before
 - a way is a set of line/polylines with a unique set of segments 

this would mean that ways could be disjoint, but not overlapping.

> I'm also thinking about long WAY's here when editing is done by
> different users at different times. For example, turning the
> hundreds if not thousands of SEGMENT's making up the M6 motorway is
> not something that is likely to be done in one shot, or even by a
> single user.

it is useful to have a type for contiguous sections of roads, though, 
as they can be used to do route planning and things like that. you 
can measure their length, but you can't measure the length of 
discontinuous segments without making some assumption about how 
they're connected.

> >> > 3. Any comments on the nomenclature change of Street to WAY
> >> > and Area to ZONE
> >>
> >> Fine to me.
> >
> >"street" and "area" are already implemented and being used, so it
> >would be a hassle to change them unless there were a really good
> >reason?
> Is "street" being used already? I thought not. Anyway, what the
> name is on the database does not need to be the name used for the
> discussion, especially with respect to what end users want
> supported in their maps. The data transport mechanism can always be
> the method of "mapping" one name to another anyway. I originally
> picked WAY because it better fitted the many polyline types present
> on a traditional map, at least a lot more than street does. It also
> kept the concept of a streetmap rather than using a generic "line"
> or "polyline", which I felt was better for map feature discussion
> purposes.

yeah, my mistake, we're using "track" apparently.

> As for Area or ZONE I really don't care. ZONE I think is used more
> generally to describe different types of area and hence why I
> picked it. Using ZONE for discussion would I hope generate
> additional ideas for map features not seen on conventional maps.
> i.e. that a ZONE can describe any area on a map as a specific
> layer. For example, on traditional maps a housing estate is
> normally give a POI label, e.g. Baker Estate. Creating a ZONE for
> Baker Estate which additionally encompasses the entire map features
> held within its boundaries has some useful additional extension
> possibilities for OSM.

likewise, postcode, electoral boundaries, woodlands, bodies of water, 
etc... are all proper area/zones. if we can get the level of detail 
its possible that large buildings can have their walls as area/zones 

personally, i'm not attached to either nomenclature, just thinking 
about the practicality of changing all the existing code that uses 
the existing system.



More information about the dev mailing list