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...).
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.
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.
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.
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.
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.
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.
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.
Groeten,
Thomas
Sander Deryckere schreef op 31-10-2014 19:42:
Marc, die bug moet ondertussen opgelost zijn.
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).
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.
Groeten,
Sander
Op 31 oktober 2014 18:54 schreef Jo <winfi...@gmail.com
<mailto:winfi...@gmail.com>>:
Zou het een idee zijn om ook de gebouwen voorzien van een fixme
aan zo'n GPX-bestand toe te voegen?
Dan kunnen we ook via die weg terugkoppelen dat extra survey nodig
is, in geval van twijfel.
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.
De MapCSS zal waarschijnlijk morgen beschikbaar zijn.
Jo
On Oct 31, 2014 4:23 PM, "Sander Deryckere" <sander...@gmail.com
<mailto:sander...@gmail.com>> wrote:
Nog wat verder gewerkt aan de tools.
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.
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).
Als je de GPX maar voor 1 straat wil hebben, dan vul je best
de straat-filter bovenaan de pagina in.
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.
Ik hoop dat dit een goede manier is om gemakkelijk alle
probleemgevallen te bezoeken.
Groeten,
Sander
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
