<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hallo Thomas,<br><br></div>Mooi werk (Sander ook natuurlijk!).<br><br>Eerst de vraagjes op het einde. De source hoort volgens mij thuis op de changeset en niet op elk object apart.<br><br></div>JOSM gooit een aantal tags automatisch weg, voordat er geupload wordt. created_by en odbl. De rest van de lijst zit in de verwijizing die Marc aangaf.<br><br></div><div>Bij mijn importscripts voor TEC en De Lijn, voeg ik odbl=new/odbl=tttttt toe (mbv MapCSS wordt dat dan een soort grafische todolist) en zet ik overbodige adresgegevens in created_by. Deze zijn dan wel overbodig voor de bushaltes, maar soms is het interessant om te weten bij welke straat zo'n halte hoorde, of gewoon nog maar om te zien dat een straatnaam in OSM waarschijnlijk fout is. (Dat was voordat we de beschikking hadden over AGIV en CRAB).<br></div><div><br></div>Wat de (foute) huisnummers betreft die wel in OSM, maar niet in CRAB zitten. Volgens mij zou het beter zijn om die volledig op te bouwen met dat soort discardable tags, ipv addr:housenumber. Dat resulteert dan in tagloze nodes die door de validatie in JOSM worden gerapporteerd in het geval iemand op upload zou drukken, voordat deze manueel werden verwijderd. Of ze stomweg zou vergeten, zoals mij nog wel zou kunnen overkomen...<br><br></div>Ik kan de MapCSS aanpassen zodat die er nog prominenter uitspringen dan de rest.<br><br></div>Als die MapCSS 'klaar' is, dan zal ik ervoor zorgen dat die gemakkelijk beschikbaar wordt in JOSM.<br><br></div>Wat de conversie betreft. Ik zou geneigd zijn om dat zootje eerst helemaal in PostGIS te laden.<br>Dan een Overpass query en die info in een aparte tabel. Het probleem is dan echter dat je ergens een platform nodig hebt, om dat te draaien en te serven + web frontend.<br><br></div>Het voordeel is dat achteraf queries schrijven dan een stuk gemakkelijker wordt en dat je ook progress reports kan maken.<br><br></div>Als we daar ooit een platform voor hebben, zou het niet slecht zijn, als we dat ook voor De Lijn en TEC konden gebruiken. Nu doe ik dat zowat dagelijks op mijn portable, maar wat als ik wegval? In Frankrijk hebben ze servers, in Nederland misschien ook. Eventueel wil ik het daar wel eens vragen.<br><br></div><div>Zelf iets opzetten en hosten zie ik, eerlijk gezegd, ook niet zitten. Vandaar dat ik de oplossing van Sander wel elegant vind.<br></div><div><br></div>Jo<br><div><div><div><div><div><br><br><div><br><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">Op 25 oktober 2014 18:46 schreef Thomas <span dir="ltr"><<a href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</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>Ik ben inmiddels bijna klaar met het
      nieuwe script dat de adressenlijst (in plaats van de
      adresposities) moet beschikbaar stellen via de website die Sander
      gemaakt heeft.<br>
      <br>
      Het oude script kon ik maar voor kleine stukjes hergebruiken omdat
      het bestandsformaat en de datastructuur toch redelijk anders zijn.
      Ik ben uitgegaan van precies dezelfde JSON-uitwisselbestanden te
      genereren zodat de website wel volledig compatibel is (op
      misschien wat extra tags in javascript na dan). Het was niet
      eenvoudig om een goed werkend script op te zetten vanwege de door
      Sander genoemde coderingsproblemen en vanwege het feit dat deze
      adressenlijst in feite 1 grote tabel is tegenover de adresposities
      die in feite een 'database' zijn of een collectie van kleinere
      tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes
      aan. <br>
      <br>
      De beschikbare modules om GML in te lezen in python bleken niet
      robuust genoeg om én met de vreemde codering om te gaan én met de
      enorme omvang van het bestand (ca. 3GB). Daarom heb ik ervoor
      gekozen om als bron het shp-bestand te gebruiken (dat 'slechts'
      1GB in omvang is, door een efficiëntere datastructuur). Daarmee
      kreeg ik wel alles aan de praat.<br>
      <br>
      Ik ben nu een aantal extra checks in de code aan het inbouwen en
      te kijken wat handig is qua extra tags (evt. gekoppeld aan wat
      CSS). Het blijft ook wat worstelen met de omvang. Mijn eerste
      tests werken in elk geval bij mij. Als het een beetje wil komt dat
      dus dit weekend af. Ook alle gemelde 'problemen' met de huidige
      dataset ga ik bekijken in deze nieuwe dataset.<br>
      <br>
      Voor alle duidelijkheid: voor de gebruikers verandert er weinig
      tot niets tegenover de huidige versie. Belangrijkste wijzigingen
      zijn het feit dat er punten zonder positie zullen zijn en dat er
      misschien wat extra tags automatisch ingeladen worden in JOSM als
      je een straat importeert. Die extra tags moeten helpen om de
      informatie naar waarde te schatten. In elk geval in deze eerste
      test-fase kunnen ze zeer handig zijn om beter bepaalde zaken te
      begrijpen.<br>
      <br>
      Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags
      die ik in JOSM inlaad maar die niet in OSM thuishoren. Zijn er
      alternatieve patronen voor dit soort “tijdelijke” werk-tags die
      OSM nooit mogen bereiken? In de link die Marc eerder doorstuurde
      lees ik vooral dat onze Nederlanders een aantal overbodige tags in
      OSM hebben zitten n.a.v. een aantal imports. Het lijkt me op zich
      een mooi streven om al dat soort tags buiten OSM te houden, wat
      onze 'import' betreft.<br>
      <br>
      Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of
      willen we dit juist vermijden omdat het toch al niet om een
      automatische import gaat?<br>
      <br>
      Groeten,<br>
      Thomas<br>
      <br>
      Sander Deryckere schreef op 25-10-2014 17:52:<br>
    </div>
    <blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>Hmm, blijkbaar hebben alle tabellen een
                    mogelijkheid tot deleten via "einddatum".<br>
                    <br>
                  </div>
                  En blijkbaar gaat dat niet altijd samen. <br>
                  <br>
                </div>
                Ik heb nu net eens het script laten lopen met alle
                records waar "einddatum" bijstond genegeerd, en dat
                resulteert vooral in terreinobjecten die genegeerd
                worden, waardoor er vooral extra adressen zonder positie
                zijn :/<br>
                <br>
              </div>
              Heb ook eens de Koningin Louisa-Marialaan bekeken met die
              nieuwe data, en daar blijkt er nu geen verschil te zijn
              O_o<br>
              <br>
            </div>
            Dus denk ik dat ik het script nog niet zal aanpassen.<br>
            <br>
          </div>
          Groeten,<br>
        </div>
        Sander<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">Op 25 oktober 2014 16:11 schreef Sander
          Deryckere <span dir="ltr"><<a href="mailto:sanderd17@gmail.com" target="_blank">sanderd17@gmail.com</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr"><br>
              <div class="gmail_extra"><br>
                <div class="gmail_quote">Op 25 oktober 2014 14:48
                  schreef Sus Verhoeven <span dir="ltr"><<a href="mailto:susvhv@gmail.com" target="_blank">susvhv@gmail.com</a>></span>:<span><br>
                    <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                      <div dir="ltr">
                        <div>
                          <div>In Leopoldsburg 3970 op de
                            Koningin-Louisalaan is er in CRAB een hele
                            reeks huizen met dubbele huisnummers niet op
                            dezelfde plaats, in GRB staat er maar een
                            van deze reeksen. <br>
                          </div>
                          Eigenaardig.<br>
                          <br>
                        </div>
                        Sus<br>
                      </div>
                      <br>
                    </blockquote>
                    <div><br>
                    </div>
                  </span>
                  <div>Dit lijkt een straat die onlangs hernummerd is,
                    en waarvan de oude nummers nog niet verwijderd zijn.<br>
                    <br>
                  </div>
                  <div>Ook de GRB basiskaart is niet volledig duidelijk.
                    Zo is er daar een nummer 13-125 te zien, wat een
                    veel te grote range is om te kunnen kloppen. Ik zou
                    voorstellen om eens ter plaatse te gaan kijken wat
                    er nu echt juist is.<br>
                    <br>
                  </div>
                  <div>Volgens de documentatie van de databases zouden
                    ze verouderde nummers moeten deleten door er een
                    "einddatum" aan te geven. In het extract script test
                    ik ook op die einddatum, dus als ze correct
                    verwijderd zijn, dan zouden ze niet meer in de data
                    mogen voorkomen. <br>
                    <br>
                  </div>
                  <div>Het is natuurlijk niet eenvoudig om in dit geval
                    te controleren als het script of de data fout is,
                    omdat het nu eenmaal niet vaak gebeurt dat een
                    straat hernummerd wordt.<br>
                    <br>
                  </div>
                  <div>In Leuven werd onlangs een straat hernummerd (zie
                    <a href="http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793" target="_blank">http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793</a>)
                    en ik denk dat de CRAB data overeenkomt met de
                    huidige data, dus dat de verwijderde nummers wel
                    degelijk niet meer zichtbaar zijn. Maar 1 voorbeeld
                    is natuurlijk wat weinig om op voort te gaan.<br>
                    <br>
                  </div>
                  <div>Groeten,<br>
                  </div>
                  <div>Sander<br>
                  </div>
                </div>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
Talk-be mailing list
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br></blockquote></div><br></div>