[Openstreetmap-dev] Data Primatives & schema
Andy_J_Robinson at blueyonder.co.uk
Wed Dec 21 14:55:57 GMT 2005
Matt Amos wrote:
>Sent: 21 December 2005 14:04
>> 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.
>(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).
ok, think that covers what can go on the wiki.
>> 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
Agreed, although not sure there needs to be an extra type. I think we should
try to keep to the one linear element multiple and logic says that each one
should be contiguous. Just means that there is more than one making up some
roadWAYs for example. If someone edits and joints up two separate line
sections, then could you at that time merge the properties of the two
(sounds painful though) and generate a single uid for the new longer WAY?
For route planning, doesn't getting back to individual connected SEGMENTS
provides the best route optimization from A to B, however that would require
each segment to have its own speed and other route attributes assigned to
it, unless when missing they can inherit these from a WAY to which the
>> >> > 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
>> 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
>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.
Agreed, I am going to use WAYS's and ZONE's for the map feature discussions
but those producing software and working with the database need to decide if
any changes to their nomenclature are actually required. I suspect that for
database and software use the NODE, LINE SEGMENT, POLYLINE and POLYGON are
the most logical to use, even if all the features typically associated with
the latter are not implemented.
Cheers again Matt
More information about the dev