[Tagging] Proposal for a generic : type=multilinestring
sly (sylvain letuffe)
liste at letuffe.org
Thu Jan 26 15:02:42 GMT 2012
On jeudi 26 janvier 2012, LM_1 wrote:
> In the proposal it says:
> "If you have one way making up the line string ring and it does not
> describe something in its own right, you may also put these tags on
> the relation and leave the relation untagged." - that does not really
> make sense to create such relation (one way tagged relation would make
> splitting the way easier).
Oups, looks like a copy paste error, there are no reasons to have rings for
those relations and instead of "relation" read "way" for the 2nd relation,
I'm changing it in the wiki.
> "The order of the relation members does not matter (but properly
> sorted member lists can help human editors to verify completeness)." -
> I believe it should be always sorted, yet routers/renderers should not
> rely on it.
Well, I'd say "it's better if" but since it will not always be the case, data
consumers should not rely on it.
A API server side re-ordering whould be cool, but that's not part of the
> How would it be used in this situation?: border of two countries (A,
> B) is also border of lower administrative divisions (AC, AD in country
> A and BE,BF in country B). going along the border you go through
> different combinations (A-B all the way; AC-BE->AD-BE->AD-BF; see
> image). In reality there would be more than two levels and therefore
> much more combinations.
Either you keep this model for the higher admin entity (country) like it is
used now sometimes with type=boundary_segment, or, at your option, or your
local community's, goes as deep as you want. That's also why this
proposition, unlike the type=multipolygon one, expressly states that it can
be used recurrently with other type=multilinestring as members
> How would it solve the case of river bifurcation if the river merges
> together (river island, the same river flows on both sides)?
It will not.
However, it can be used for the main line river, wich, in turn, could be
member of a type=river relation.
I designed type=multilinestring as a geometry model, not as a fancy
ever-changing relation with roles or nodes. It can be used as being the
member of other complex relation grouping several features, but building it's
geometry is meant to be as stable in time as possible.
> How would it solve similar case of streets (lanes for different
> directions split for some time and later merge together)?
Same, it will not.
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
More information about the Tagging