<div dir="ltr">Answers inline.<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-16 23:13 GMT+02:00 André Pirard <span dir="ltr"><<a href="mailto:A.Pirard.Papou@gmail.com" target="_blank">A.Pirard.Papou@gmail.com</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>On 2014-06-16 01:58, Jo wrote :<br>
    </div><div class="">
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>Hi,<br>
                  <br>
                </div>
                The conversion is done. Municipality names are converted
                to lower case, restoring the accents. Route_ref is
                calculated.<br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    Many thanks Jo!<br></div></blockquote><div><br></div><div>You're welcome<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">

    A few remarks.<br></div></blockquote><div><br></div><div>Oh no! <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    As there were as usual no replies on this list to my remarks about
    missing bus line numbers and accent-less uppercased place names, I
    wrote to the TEC myself.  They recognized my remarks as valid points
    and they said that they will fix these problems, but no sooner than
    September.  I'll cc: you.<br>
    <br>
    I wonder if it wouldn't be wiser to "let's start !" in September
    with that data rather than do it twice.<br></div></blockquote><div><br></div><div>Why would we be doing it twice? What they will provide sometime after September should have exactly the same contents as what my scripts are calculating from the data they provide.<br>
<br></div><div>Anyway, I don't see why it was needed to bother TEC with this. They provide the data as is and it's our responsability to convert it to something we can work with. I'm actually rather surprised you got a positive answer from them.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Whatever I try, I see accent-less uppercased place names in your
    file.<br></div></blockquote><div><br></div><div>What did you try? 2 files found their way into the zip file. I hope you were looking at the most recent one. I'm recreating them now. In the mean time it's possible to determine whether a stop is new or not. i.e. if a stop with that ref is already present in the Openstreetmap data I'm downloading with Overpass.<br>
<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    I thought that you had found the line numbers, but I don't see them.<br></div></blockquote><div><br></div><div>They are in the route_ref key. Where did you expect to find them?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
    <br>
    My file was displaying the lines (without number). Yours not.  Here
    is an additional layer to display them.<br></div></blockquote><div><br></div><div>I never saw your file before I started. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
    <pre><a href="https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2" target="_blank">https://dl.dropboxusercontent.com/s/ty49nmfdb2vfz4m/TEC_2014_04-Lignes.2.osm.bz2</a></pre>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div><div class="">All that's missing at the moment is comparison with
              existing data already present in OSM. I'm already doing
              that for the stops of De Lijn, so the process exists. It
              merely needs to be adapted a bit in the scripts I created.<br>
              <br></div><div class="">
              I'm not adding source on the objects anymore. Instead I
              add source tags on the changeset as a whole.<br>
            </div></div>
          </div>
        </div>
      </div>
    </blockquote>
    On one hand, using a source= tag is highly recommended in the bus
    stops and lines, if not required.<br></div></blockquote><div><br></div><div>It's certainly not required. The tendency is towards adding source on changesets nowadays. Look at buildings in France to see what adding source on objects does.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    On the other, you must of course be able to tell data that was added
    by copying the elements of your file from OSM.org data that existed
    before your publication and that must be updated.<br>
    It's not a matter of how <b>you</b> make updates and tag
    change-sets, but of how <b>the mappers</b> will do it.<br>
    They'll File>Upload those updates the normal way, without your
    change-sets tags, I don't know how to do it.<br></div></blockquote><div><br></div><div>People are responsible for adding those changeset tags themselves.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
    If you use <b>source=survey 2014-06  TEC 2014-04</b> in bus stops
    as I recommend, you will both comply with the source requirement and
    be sure to find the indication that they contain your file's data
    and can be deleted from the remaining-to-be-updated file.<br>
    If an existing element does not contain <b>source=survey 2014-06</b><b> 
      TEC 2014-04</b> or later, it will be kept in the
    remaining-to-be-updated file.  If a mapper further updates the data,
    he is kindly requested to use a new date such as <b>source=survey
      2014-07</b> or <b>source=survey 2014-06-21</b> .</div></blockquote><div><br> <br></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=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>As for the operator, I prefer to use simply TEC.<br>
          </div>
        </div>
      </div>
    </blockquote></div>
    No problem for me with <b>operator</b>, but (Sorry Julien, fourth
    time) if you use <b>network</b>=<a href="http://tec-wl.be" target="_blank">tec-wl.be</a> that's not an URL and <a href="http://www.openstreetmap.org/node/857875464" target="_blank">that
      is not clickable here</a>  although we agreed using an URL (<b>network</b>=<a href="http://tec-wl.be" rel="nofollow" target="_blank">http://tec-wl.be</a>   <a href="http://www.openstreetmap.org/node/1645537259" target="_blank">which is clickable here</a>)  then please add
    website=<a href="http://tec-wl.be" rel="nofollow" target="_blank">http://tec-wl.be</a>.</div></blockquote><div><br></div><div>I don't see the need to add network. Especially if it would be duplicating what was already in operator. Which entity the stop belongs to, can be determined in a trivial way from the first letter of the ref of the stop (for TEC, in the first digit for the stops of De Lijn). That's what network could be used for, but it's not needed.<br>
 <br></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=""><br>
    <br>
    The OSM file with all the stops in Wallonia can be found here:<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><a href="https://dl.dropboxusercontent.com/u/42418402/TEC.osm.zip" target="_blank">https://dl.dropboxusercontent.com/u/42418402/TEC.osm.zip</a><br>
        </div>
      </div>
    </blockquote>
    <br></div>
    I think you should say that it must not be used for updates right
    now.</div></blockquote><div><br></div><div>As always, everybody can use it: 1. at their own risk and on their own responsability, 2. by double checking everything is correct before pressing upload. That's what I'm doing at the moment.<br>
<br></div><div>For all the stops I'm adding, I'm double checking the position and the tags. It's not a matter of simply bulk uploading them. If it were that simple, I could simply do it in one go.<br></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=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>What we still need to discuss:<br>
        </div>
      </div>
    </blockquote></div>
    The topics mentioned above and<div class=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Is it OK to keep the zones as 4 digits? For me it's better,
          as it makes them unique. It's not what can be read at the
          stops in the streets though (There you'll find the last 2
          digits).<br>
        </div>
      </div>
    </blockquote></div>
    I find the 4 digits all-right because if you don't want to see the
    first two you just close your left eye but if they weren't there and
    if you wanted to see them it wouldn't be possible ;-)<br>
    What do the left two digits mean?  Wouldn't that be the place for
    the line number? Following "be.wa."?<br></div></blockquote><div><br></div><div>As is often the case. I don't know what you are talking about. The first 2 digits of the zone number are obviously a way to group zones which are in the same region.<br>
<br></div><div><br><br></div><div>I found a new 'problem'. I started adding/editing stops for buses of TEC which start at Brussels south station.<br><br></div><div>123, 124 and W are from the Brabant-Wallon entity<br>
</div><div>365a is from the Charleroi entity.<br><br></div><div>All these stops have 2 refs from TEC, so I consider them as 2 stops which are located at the same position representing them with separate nodes, as I had started doing for De Lijn and MIVB/STIB. The result is that some stops are now split into 4 nodes.<br>
<br>I consider this necessary to make maintenance feasible. But the least one can say, is that it looks odd...<br><br></div><div>I didn't upload yet, so I don't have an example at the moment. It's quite a bit of work, so it might take me days rather than hours.<br>
<br></div><div>Jo<br></div></div></div></div></div>