<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Op 1 november 2014 01:43 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Je verbeteringen vind ik zeer goed
Sander! Bij mij laadt de pagina nu echter niet, met een
foutmelding “'section' is null” op loadstreets.js ~664. Het lijkt
fout te gaan wanneer in de URL de GET-parameter collapsedSections
geset wordt, maar zonder waarde blijft. Als ik die parameter
handmatig uit de URL verwijder doet hij het perfect! (tot ik op
update druk...).<br></div></div></blockquote><div><br></div><div>Hmm, dat was dezelfde bug als die van Marc. Ik had die opgelost, maar mijn push naar de online repo was niet doorgekomen. Zou nu ECHT opgelost moeten zijn. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
<br>
Ik ben (helaas) nog steeds bezig met het script. In mijn vorige
mail schreef ik dat de postcodes en de gemeenten schijnbaar niet
helemaal overlappen. Hoewel dat zeker klopt, ben ik er nu van
overtuigd dat ik met die check toch wel meer dan 100 fouten in het
CRAB gevonden heb. In de 250+ adrespunten die ik zo
geïdentificeerd heb, blijkt het in héél wat gevallen om een
postcode en een gemeente te gaan die helemaal niet aan elkaar
grenzen, en soms meer dan 50km uit elkaar liggen. Het moet dus wel
om fouten gaan. Daarmee heb ik dus een forse set fouten
geïdentificeerd... Heeft iemand hier een goede ingang bij het AGIV
om dit door te geven? Ik werk nu aan een nette lijst met alle
gegevens. <br>
<br></div></div></blockquote><div>Ha, net het volgende ontdekt. Voor de fusie in de jaren '70 had Oostnieuwkerke de postcode 8820. Sinds de fusie hebben we echter de postcode van Staden (8840). Raar genoeg is 8820 nu wel de postcode van Torhout (ik weet niet wat hun postcode voor de fusie was). <br><br></div><div>Als je nu dus de adressen van 8820 bekijkt (<a href="http://aptum.github.io/import.html?pcode=8820&loadOsm=true&collapsedSections=comparison,export,data#data">http://aptum.github.io/import.html?pcode=8820&loadOsm=true&collapsedSections=comparison,export,data#data</a>), dan zie je dat er 2 adressen nog altijd in Oostnieuwkerke liggen (2 dorpen ten zuiden van Torhout).<br><br></div><div>Kan je nog eens controleren als die adressen in de adressenlijst niet aangegeven zijn als "verwijderd" op een of andere manier? Als dat niet gebeurd is, dan zij dat duidelijk 2 fouten in de CRAB adressenlijst. En waarschijnlijk dezelfde fout als die andere 100 fouten.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
Dit is eigenlijk (naast dan de afwijkende adres-labels) de enige
inconsistentie die ik op basis van de data zelf kan vaststellen in
de adressenlijst. Alle adressen vallen netjes onder een postcode
en zo. Dus voor onze huidige opzet is er helemaal geen probleem,
zoals Sander al aangaf. Ik neem de vraag naar postcodes en
gemeenten wel mee; ik zorg dat deze in de JSON aanwezig zijn. Een
verdere verwerking via de javascript is dan triviaal. Het
importeren van die gegevens in de vorm van discardable tags lijkt
mij ook helemaal geen probleem. Als dat kan bijdragen aan het
controleren van die gegevens in OSM lijkt me dat enkel een
toevoeging.<br>
<br>
De uitspraak van Ben dat er situaties zijn waar postcode, straat
en huisnummer niet identificerend zijn (naast de busnrs/apptnrs
dan) vind ik intrigerend. Ik ben wat checks aan het doen op de
dataset om te kijken of ik dit soort situaties kan vinden. Ik kom
hier nog op terug, want onze huidige classificatie is wel
gebaseerd op het feit dat die drie elementen identificerend zouden
moeten zijn.<br>
<br>
Voor wat betreft de relaties tussen de huisnummers en straten
sluit ik mij deels aan bij Ben: vanuit mijn
informatica-achtergrond ben ik een groot fan van dit soort
relaties. Vanuit mijn ervaringen met niet-informatici weet ik
echter dat dat soort abstracte koppelingen die geen zichtbare
weerslag hebben en puur een ordening op meta-niveau zijn vaak voor
ellende zorgen. Ik vind dat soort relaties een zeer elegante
oplossing, maar tegelijkertijd te abstract voor een brede
toepassing. <br>
<br>
Het toevoegen van postcode en gemeente tags op een adres vind ik
dan weer lastig; waar houdt het op? Ik denk dat iedereen het
absurd vindt om op elke tag het land te mappen, maar waarom wel de
gemeente? Wat mij betreft vormen die gemeentegrenzen toch een
basisonderdeel van de kaart. Als we al niet op gemeentegrenzen
kunnen vertrouwen dan wordt het wel heel lastig. Voor de postcodes
ligt dat weer iets anders. Postcodes hebben volgens mij puur een
functie voor postadressen. Wat mij betreft mag dat op de adressen
getagd worden. Een postcode is naar mijn gevoel ook echt iets wat
een eigenschap is van een adres, in tegenstelling tot een gemeente
dat echt voor een grondgebied staat. Het argument van Jo over de
data-omvang lijkt mij de belangrijkste om het aantal tags toch
proberen te beperken, en daarom toch de gemeente aan de
gemeente-contour over te laten in plaats van deze als tag te
registreren.<br>
<br>
Dat deze ingevoerde gegevens nu misschien niet altijd overeenkomen
met wat uit een gerenderde kaart komt lijkt mij niet het
belangrijkste. Deze gegevens kunnen in elk geval gebruikt worden
om de contouren (met name dan de postcodes) te controleren op
afwijkingen ten opzichte van de ingevoerde nodes. Op die manier
kan eenvoudig de data op de nodes getagd worden en kunnen de
contouren verbeterd worden, tot die tijd dat andere systemen wel
met de informatie op de nodes gaan werken. Het beheer van de
contouren lijkt me in elk geval eenvoudiger te worden met de data
op de nodes.<br>
<br>
Nuja; ik zorg dat alle gegevens via JSON beschikbaar zijn en
bijgewerkt worden. Met veranderende inzichten kan dan alsnog
eenvoudig beslist worden deze informatie al dan niet in JOSM in te
laden, al dan niet via discardable tags.<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 31-10-2014 19:42:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Marc, die bug moet ondertussen opgelost zijn.<br>
<br>
</div>
Jo, dat is idd een optie. Maar ik vraag me af als het wel in
deze tool past. De fixme gaat in veel gevallen niet over het
adres, maar ook over de naam van de winkel, de openingsuren,
... Daarnaast zijn er ook veel fixmes die wel moeten
opgelost zijn, maar die niet op een gebouw staan. Ik denk
dat dit werk is voor een andere tool (het is sowieso al
mogelijk met overpass turbo, maar het is iets moeilijker
overpass queries te schrijven op een telefoon).<br>
<br>
</div>
Bedankt voor de CSS, kan je het meteen al documenteren op de
wiki? Ik ben momenteel bezig met sommige van die wiki pagina's
te vertalen.<br>
<br>
Groeten,<br>
</div>
Sander<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 31 oktober 2014 18:54 schreef Jo <span dir="ltr"><<a href="mailto:winfixit@gmail.com" target="_blank">winfixit@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p dir="ltr">Zou het een idee zijn om ook de gebouwen
voorzien van een fixme aan zo'n GPX-bestand toe te voegen?</p>
<p dir="ltr">Dan kunnen we ook via die weg terugkoppelen dat
extra survey nodig is, in geval van twijfel.</p>
<p dir="ltr">ook de adressen waar wij zeker van zijn, maar
die anders in crab zitten zouden we van een tag kunnen
voorzien om de terugkoppeling upstream te
vergemakkelijken.</p>
<p dir="ltr">De MapCSS zal waarschijnlijk morgen beschikbaar
zijn.</p>
<span><font color="#888888">
<p dir="ltr">Jo</p>
</font></span>
<div class="gmail_quote">
<div>
<div>On Oct 31, 2014 4:23 PM, "Sander
Deryckere" <<a href="mailto:sanderd17@gmail.com" target="_blank">sanderd17@gmail.com</a>>
wrote:<br type="attribution">
</div>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div>Nog wat verder gewerkt aan de tools.<br>
<br>
<br>
</div>
<div>De straten worden nu altijd op een kaartje
weergegeven, met een kleurencode om aan te
duiden hoe compleet die zijn. De links in die
popup werken zoals de links in de tabel.<br>
<br>
</div>
<div>Verder heb ik er ook nog een optie aan
toegevoegd om te exporteren naar GPX. Onderaan
de tabel vind je drie knoppen om die drie
kolommen te exporteren naar GPX, en zo alle
probleemgevallen in je gemeente naar je GPS of
smartphone te downloaden (door de simpele html
werkt de site ook tamelijk goed op een
smartphone, waardoor je niet met kabeltjes moet
klungelen, maar het rechtstreeks daar kan
downloaden).<br>
<br>
</div>
<div>Als je de GPX maar voor 1 straat wil hebben,
dan vul je best de straat-filter bovenaan de
pagina in.<br>
<br>
</div>
<div>Om die GPX bijvoorbeeld met OsmAnd te
gebruiken, sla je hem op onder
/sdcard/osmand/tracks, en dan kan je die
gemakkelijk weergeven en op de markers drukken
om te zien over welk adres het gaat.<br>
<br>
</div>
<div>Ik hoop dat dit een goede manier is om
gemakkelijk alle probleemgevallen te bezoeken. <br>
</div>
<div><br>
</div>
<div>Groeten,<br>
Sander<br>
</div>
</div>
<br>
</div>
</div>
<span>_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">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>
</span></blockquote>
</div>
<br>
_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">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>
<br>
<fieldset></fieldset>
<br>
<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>
</blockquote>
<br>
</div></div></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></div>