2012/8/1 Peter Wendorff <span dir="ltr"><<a href="mailto:wendorff@uni-paderborn.de" target="_blank">wendorff@uni-paderborn.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Am 01.08.2012 16:01, schrieb Simone
      Saviolo:<br>
    </div><div class="im">
    <blockquote type="cite"><br>
            Do you know how many editors are out there? and there are
            bots all kinds of scripts with API upload support ... Feel
            free to fix all of them. As far as I know not a single
            editor for mobile applications has any relation support.<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>...and here's why CSS is now a forgotten, pityful attempt
        that has justly been abandoned. No, wait. <br>
      </div>
    </blockquote></div>
    There are two big differences between CSS and the proposed relation
    stuff.<br>
    1) The inventors of CSS provided a working implementation for core
    CSS features<br>
    2) For a considerably long time css was used only very sparse and
    most of the time with a html4 styling "fallback".<br>
    <br>
    Nobody arguments about the proposed use of relations per se, but
    it's far from enough to propose something.<br>
    1) Proposing one option is not the same as deprecating another, and
    that's what some want to do here.<br>
    2) Support in editor software does not rely on fixed rules only to
    use relations, so that could be added even before "switching", and
    both variants may co-exist for some time.<br>
    <br>
    The arguments mainly are:<br>
    relations are the better data model<br>
    therefore let's deprecate ref tags on ways.<br>
    <br>
    instead of:<br>
    relations are the better data model<br>
    let's make editors great enough that relations are on top of that
    easier to use for mappers <br>
    let's make the API better by fixing the performance issues that
    occur regularly when dealing with big relations (or very long ways)<br>
    Let's then encourage by arguments instead of rules to use relations
    - as there's no good counter argument any more: At this stage they
    are as easy to use, better to maintain and the cleaner data model.<br>
    <br>
    This is a big difference.<br>
    The first approach is what's tried here, and get's bad critics from
    some others, because "usually" these attempts end up with new
    proposals and questions to the old developers "why don't you support
    that? it's the 'only' way to do it right" - or something like that.</div></blockquote><div><br></div><div>It's the same thing as CSS, actually. It's not a matter of providing a first implementation. It's a matter of saying "this is how you can expect data to be". If you don't say that (which is what OSM keeps doing) no-one will *want* to use inconsistently-modelled data. Also, we shouldn't be afraid if only two applications out of 500 support the full data model. </div>

<div><br></div><div>Also, as long as we keep the good way together with the limited way, most consumers won't bother switching to the better model. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div text="#000000" bgcolor="#FFFFFF"><div class="im"><br>
    <blockquote type="cite">
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="gmail_quote">
          <div>The problem of roads tagging, was brought up in talk-cz
              several times.<br>
              The problem is that current tagging scheme is semantically
              wrong - e.g.<br>
              we have only one primary road number 2, but OSM data says
              we have<br>
              several hundreds of them. 
          <blockquote type="cite"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
        </div>
      </blockquote>
    </blockquote></div></div></blockquote></blockquote></div>
    That's wrong, as you don't read it correct.<br>
    It's based on the assumption, that one named street is one object in
    OSM,<br>
    But the osm object isn't the "main street", it's a part of street
    that "has the name main street".<br>Other parts of the street, connected to that part, have the same
    name. </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="im"><br>
    <blockquote type="cite">
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="gmail_quote">
          <div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The same
              for named residential streets in<br>
              cities. This causes several problems.<br>
            </blockquote>
          </div>
        </div>
      </blockquote>
    </blockquote></div>
    Let's use the residential street example.<br>
    How do you as a human being decide where a street ends?<br>
    At every intersection there's a new street sign - repeating the same
    street name, so you as a human decide that the next segment is part
    of the same street.<br>
    Well... that's easily to be implemented in software, too: collect
    connected streets with the same name and you're done.<br>
    <br>
    But that's not the only argument?<br>
    Sure: sometimes you don't want to deal with one street as one
    street, e.g. because a part of it is a pedestrian area, and you want
    to deal with that differently - well, then use the same approach
    based on additional parameters, e.g. only use parts of that street
    that can be used by cars etc.<br>
    <br>
    Sure: We could add different relations for that, but is it really
    helpful, as soon as that algorithm is once implemented in your
    software?<div class="im"><br>
    <br>
    <br>
    <blockquote type="cite">
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="gmail_quote">
          <div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              It makes it hard for data producers to edit the road,
              because you have<br>
              the information about it duplicated over several hundreds
              of segments.<br>
            </blockquote>
          </div>
        </div>
      </blockquote>
    </blockquote></div>
    May be hard, but as mentioned before: most common attributes aren't
    changed very often, and once tagged that's no problem again.<br>
    Editor software supports to repeat last used tags nowadays, and so
    on.<br>
    <br>
    On the other hand:<br>
    Consider a route relation. A changing ref may be changed easily now,
    as it's only editing the relation once.<br>
    What about a speed limit implemented for some kilometers for a
    while, e.g. because of a bad surface?<br>
    Do you add that to the individual segments now?<br>
    or do you add a new relation, because it's - as you say - easier to
    handle that?<br>
    As you want to deprecate the on-way-variant, that would the way you
    go, if I understand it right.<br>
    <br>
    Now let's assume there are two construction sites that join together
    two weeks later.<br>
    You have two relations now, that are "connected" when you look on
    the members.<br>
    Do you join these to one?<br>
    If so: how is that less work than it has been before?<br>
    Without relations the last segment in between get's the construction
    tag and that's it.<br>
    <br>
    How to delete the construction site again?<br>
    Well, I personally would use the search and filter option to search
    for all ways affected:<br>
    search by name,<br>
    search by construction tag,<br>
    restrict to the bbox where the construction site is on, and delete
    the tag, done.<br>
    <br>
    that's not much more work than the other variant, where I would have
    to find a member of the relation, select the relation and delete it
    - given that the relation is used for this particular meaning only,
    and not part of a parent relation to "make it easier" to handle the
    complete road, as the construction part is redirected to this child
    relation.<div class="im"><br>
    <blockquote type="cite">
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="gmail_quote">
          <div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              It makes it hard for data consumers to present the data in
              a meaningful<br>
              way - </blockquote>
          </div>
          <div><br>
            really? I can't see that. there are many map rendering
            solutions, routing algorithms for desktop, web service,
            mobile devices ... Must be a miracle that they all function.<br>
            btw I am not aware of many using relations. <br>
          </div>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>What would consumers' assumptions be, reasonably? That any
        ways with the same value in a given tag would have to be
        considered a single thing? </div>
    </blockquote></div>
    Do you have an example of this kind of customer?<br>
    Yes, that demans for tools that support this, but it's not a big
    difference if I have to collect the geometry of a relation down
    through several relations that each other doesn't contain geometry,
    or if I join ways together, that have attributes - and usually nodes
    in common, but no relation.</div></blockquote><div><br></div><div>You are confusing ways (in OSM) with streets. Of course the way model is perfectly fit for what you describe, but not for names. I mean, it's OK if I want to know where am I - on a piece of street whose name is "Main Street". But if I'm searching for "Main Street", I am looking for *the street*, not for all of the pieces that make it up. If not all of those pieces are connected, simple geometry-stitching doesn't work. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="im"><br>
    <blockquote type="cite">
      <div>I have examples of separate streets with the same name in the
        same city, not separate, non-connected parts of the same street,
        mind you. A relation here would describe the reality without
        fail, and much more elegantly. . <br>
      </div>
    </blockquote></div>
    Sure, and nobody complains about adding a relation here, but that
    doesn't count as an argument to only use relations for every street,
    nor is it an argument for deleting/omitting ref and name tags on the
    individual ways.</div></blockquote><div><br></div><div>You've misunderstood my example. I mean that there are two streets, that have no relation (non-OSM term) between them, with the same name, in the same city. Yes, there are address conflicts between those two streets. In real life. In this case, it would be legit to be presented with two search results, but those should come from two definitions of streets, not from the stitching of several ways into two or more name-based groups. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div class="im"><blockquote type="cite">
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="gmail_quote">
          <div>nothing wrong with that. But be aware that all these local
            communities have to come up with their own solutions to use
            the data.  Is the Czech community large enough to offer
            maps, routing in all flavors and other useful applications?
            probably it's much easier to go with the flow and bear a
            with some oddities.</div>
        </div>
      </blockquote>
      <div><br>
      </div>
      <div>According to your reasoning, Germans should tell us how to
        map because they make tools and consumers. Is this correct?</div>
    </blockquote></div>
    I'm not asked here, and I don't want to get deeper into the
    discussion about strong communities overruling small communities and
    the like - that's a different topic as I hope not to argument as a
    community, but as an individual mapper.<br></div></blockquote><div><br></div><div>BTW, I'm sorry if this caused a misunderstanding, but I didn't notice you're German yourself. I wasn't claiming that you, as a German, felt strong because you are backed up by the largest community.  </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    But from my point of view your position still lacks the big thing
    about support for your proposal:<br>
    You as a community (at least you claim to speak for "the Czech
    community", probably you're right, I don't know) have decided to...<br></div></blockquote><div><br></div><div>...neither I am Czech or cohoperate with the Czech community in any way. I'll leave those questions for them to reply. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    Which tools do you use for that?<br>
    Are beginners fine with that decision?<br>
    Are they able to deal with that? <br>
    Are they able to deal with that without getting a dedicated
    introduction and explanation on how to do it?<br>
    Where do they get the corresponding instructions?<br>
    <br>
    Do you know of individual newcomers being able to understand that
    scheme without such kind of introduction?<br>
    Did anybody use it this way - without introduction - edits of
    existent relations of that kind are enough as an argument, I think.<br>
    Are these people IT/Database experts in some kind, or gps navigation
    system users that start to map out of interest?<br>
    </div></blockquote><div><br></div><div>Regards, <br></div><div><br></div><div>Simone</div>