Re: [OSM-talk-be] import AGIV CRAB-data
Jo, De documentatie over de import is ongeveer gereed (enkel nog LARA documenteren in de Engelse versie, en de beginpagina aanpassen). Zou jij de MapCSS ergens willen publiceren? Dan hoop ik binnenkort de discussie op de import lijst te herbeginnen. Bedankt, Sander Op 8 november 2014 23:20 schreef Sander Deryckere sander...@gmail.com: Op 8-nov.-2014 23:07 schreef Jo winfi...@gmail.com: Sander, Ik denk dat die addr:official_housenumber op 1 node een betere oplossing is dan al die nodes bovenop elkaar. In het begin was er ook een veld met daarin 20-28. Was dat gegenereerd, of zit dat ook ergens zo in de CRAB-data? Als je de crab info aanvinkt zal je dat veld opnieuw hebben. Dat is het huisnummerlabel veld, en toont gewoon welke nummers aan hetzelfde grb object gelinkt zijn. Dus als er 2 ingangen zijn, en de data in crab is precies tot op de voordeur, dan zullen de nodes op andere posities staan, maar ze horen wel op hetzelfde gebouw en kunnen eventueel zo getagged worden in osm. Langs de andere kant ken ik een nieuwe staat, waar de huisnummers nog niet aan gebouwen gelinkt zijn, en waar dus alle 20 huisnummers overlappen met als label 1-20. Omdat ik vanop afstand niet kan weten welke nummers nu zichtbaar zijn en welke niet, kan ik ook de tag addr:official_housenumber niet meegeven. Het enige waar die tag voor gebruikt kan worden, is als een mapper niet graag onbestaande huisnummers wil mappen, maar toch de info van het crab zo goed mogelijk in osm wil krijgen. Sus, we zitten nog maar in de testfase en dat probleem van samengevoegde huizen en gebouwen met meerdere huisnummers, is een lastige noot om te kraken. Op de hoek van de Kapucijnenvoer met de Brusselsestraat, zag ik daarnet ook een blok waarvan elke winkel een apart huisnummer heeft, maar het is wel slechts 1 gebouw. Dat opdelen in smalle appartementsblokken, klopt niet, anderzijds zou het wel interessant zijn om aan te geven welk gedeelte van het gelijkvloers elke winkel inneemt In het gebouw aan het Mercatorpad zitten meerdere bedrijven. Ze staan daar nu als aparte nodes, zonder adresinformatie. Het is, met enkel OSM-data, niet mogelijk om te achterhalen welk adres bij welk bedrijf hoort. Sommige hebben hetzelfde huisnummer en een verschillend busnummer, wat betekent dat als de adressen herhaald worden op de nodes, dat een adres/huisnummer dan meerdere malen terugkomt. Dat gebouw opdelen zou een oplossing kunnen zijn, maar waar zou je dan splitsen? Nog even en we hebben de bouwplannen ook nog nodig :-) Ik heb het mappen ervan uitgesteld tot 'k 's ter plaatse kan gaan kijken, maar ik ben niet overtuigd dat ik dan wel zal weten hoe het te mappen. Jo Op 8 november 2014 11:54 schreef Sander Deryckere sander...@gmail.com: @Glenn: Ik begrijp niet goed wat je wil zeggen. Door ze als addr:official_housenumber te taggen gaan ze net extra bovenkomen (met overpass kan je bijvoorbeeld eenvoudig zoeken waar die liggen). Een goeie geocoder (die in tegenstelling tot Nominatim ook goed werkt met Belgische adressen) zou het onderscheid kunnen maken tussen beiden, maar de geocoder kan ze ook door elkaar gebruiken als dat wenselijk is. Dus ben je nu voor of tegen die official_housenumber tag? Op 8 november 2014 09:58 schreef Verhoeven Fr sus...@gmail.com: Dag Sander, Met de script krijgt men soms opgestapelde huisnummers wanneer er in AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks opgestapeld zijn. BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van de straat, ook de opgegeven nummers op de tag van de script , 19 en 7, wijzen op niets. Dit heb ik al meermaals gespot. Voor de rest komt de script komt wel dik van pas. Groeten Sus Daarom dat er een kolom missing overlapping is. Die overlappende huisnummers liggen toch in die overlapping kolom? Of is er daar een fout mee? Die kolom is moeilijk om te behandelen, omdat het aan de mapper is om te beslissen als die meerdere huisnummers nu net samen horen, of gesplitst moeten worden over meerdere huizen. Door het in een aparte kolom te zetten kan je die moeilijkere gevallen houden voor later. Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Dag Sander, Met de script krijgt men soms opgestapelde huisnummers wanneer er in AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks opgestapeld zijn. BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van de straat, ook de opgegeven nummers op de tag van de script , 19 en 7, wijzen op niets. Dit heb ik al meermaals gespot. Voor de rest komt de script komt wel dik van pas. Groeten Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
@Glenn: Ik begrijp niet goed wat je wil zeggen. Door ze als addr:official_housenumber te taggen gaan ze net extra bovenkomen (met overpass kan je bijvoorbeeld eenvoudig zoeken waar die liggen). Een goeie geocoder (die in tegenstelling tot Nominatim ook goed werkt met Belgische adressen) zou het onderscheid kunnen maken tussen beiden, maar de geocoder kan ze ook door elkaar gebruiken als dat wenselijk is. Dus ben je nu voor of tegen die official_housenumber tag? Op 8 november 2014 09:58 schreef Verhoeven Fr sus...@gmail.com: Dag Sander, Met de script krijgt men soms opgestapelde huisnummers wanneer er in AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks opgestapeld zijn. BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van de straat, ook de opgegeven nummers op de tag van de script , 19 en 7, wijzen op niets. Dit heb ik al meermaals gespot. Voor de rest komt de script komt wel dik van pas. Groeten Sus Daarom dat er een kolom missing overlapping is. Die overlappende huisnummers liggen toch in die overlapping kolom? Of is er daar een fout mee? Die kolom is moeilijk om te behandelen, omdat het aan de mapper is om te beslissen als die meerdere huisnummers nu net samen horen, of gesplitst moeten worden over meerdere huizen. Door het in een aparte kolom te zetten kan je die moeilijkere gevallen houden voor later. Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Voor mij hoeft dat niet. Ik ben voornamelijk een OSM gebruiker en ik vermoed dat dat in geen enkele applicatie ga terugvinden. Wat mij interesseert is een huisnummer in mijn smartfone in te geven en dat die voor mij de weg uitzoekt. Ik heb mij altijd afgevraagd wat het nut was van al die buslijnen, buiten de dichts bijgelegen bushalte. Maar nu is er http://www.openlinkmap.org/ en als bus gebruiker van De Lijn is dat een grote vooruitgang, al is het moeilijk te gebruiken op een smartfone. Ondertussen is hier in de streek ook een QRcode aan iedere bushalte die naar dezelfde informatie verwijst. Maar ook die heeft nadelen, want in felle zon en met wat lichtweerkaatsing doet die het ook niet. Groeten Sus Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Je kan ook gewoon in je browser mijnlijn.be/x0zxyz intypen, als je al aan de bushalte staat. Ze hebben bij De Lijn nu ook hun mobiele site aangepast en het is nu een stuk eenvoudiger om haltes op te zoeken. In OsmAnd kan je ook op de haltes klikken, maar je kan niet doorklikken naar de realtime info. Die routes zitten o.a. in OSM, omdat je daar dan een kaart mee kan tekenen. Zoals deze bijvoorbeeld: https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png Daar heb ik de routes van De Lijn gecombineerd met de wandelknooppunten en natuurlijk de rest van de data in OSM. Dat is iets dat onmogelijk was geweest, als OSM niet bestond en als we die routes daar niet in hadden opgenomen. Jo Op 8 november 2014 18:01 schreef Verhoeven Fr sus...@gmail.com: Voor mij hoeft dat niet. Ik ben voornamelijk een OSM gebruiker en ik vermoed dat dat in geen enkele applicatie ga terugvinden. Wat mij interesseert is een huisnummer in mijn smartfone in te geven en dat die voor mij de weg uitzoekt. Ik heb mij altijd afgevraagd wat het nut was van al die buslijnen, buiten de dichts bijgelegen bushalte. Maar nu is er http://www.openlinkmap.org/ en als bus gebruiker van De Lijn is dat een grote vooruitgang, al is het moeilijk te gebruiken op een smartfone. Ondertussen is hier in de streek ook een QRcode aan iedere bushalte die naar dezelfde informatie verwijst. Maar ook die heeft nadelen, want in felle zon en met wat lichtweerkaatsing doet die het ook niet. Groeten Sus Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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
Re: [OSM-talk-be] import AGIV CRAB-data
Sander, Ik denk dat die addr:official_housenumber op 1 node een betere oplossing is dan al die nodes bovenop elkaar. In het begin was er ook een veld met daarin 20-28. Was dat gegenereerd, of zit dat ook ergens zo in de CRAB-data? Sus, we zitten nog maar in de testfase en dat probleem van samengevoegde huizen en gebouwen met meerdere huisnummers, is een lastige noot om te kraken. Op de hoek van de Kapucijnenvoer met de Brusselsestraat, zag ik daarnet ook een blok waarvan elke winkel een apart huisnummer heeft, maar het is wel slechts 1 gebouw. Dat opdelen in smalle appartementsblokken, klopt niet, anderzijds zou het wel interessant zijn om aan te geven welk gedeelte van het gelijkvloers elke winkel inneemt In het gebouw aan het Mercatorpad zitten meerdere bedrijven. Ze staan daar nu als aparte nodes, zonder adresinformatie. Het is, met enkel OSM-data, niet mogelijk om te achterhalen welk adres bij welk bedrijf hoort. Sommige hebben hetzelfde huisnummer en een verschillend busnummer, wat betekent dat als de adressen herhaald worden op de nodes, dat een adres/huisnummer dan meerdere malen terugkomt. Dat gebouw opdelen zou een oplossing kunnen zijn, maar waar zou je dan splitsen? Nog even en we hebben de bouwplannen ook nog nodig :-) Ik heb het mappen ervan uitgesteld tot 'k 's ter plaatse kan gaan kijken, maar ik ben niet overtuigd dat ik dan wel zal weten hoe het te mappen. Jo Op 8 november 2014 11:54 schreef Sander Deryckere sander...@gmail.com: @Glenn: Ik begrijp niet goed wat je wil zeggen. Door ze als addr:official_housenumber te taggen gaan ze net extra bovenkomen (met overpass kan je bijvoorbeeld eenvoudig zoeken waar die liggen). Een goeie geocoder (die in tegenstelling tot Nominatim ook goed werkt met Belgische adressen) zou het onderscheid kunnen maken tussen beiden, maar de geocoder kan ze ook door elkaar gebruiken als dat wenselijk is. Dus ben je nu voor of tegen die official_housenumber tag? Op 8 november 2014 09:58 schreef Verhoeven Fr sus...@gmail.com: Dag Sander, Met de script krijgt men soms opgestapelde huisnummers wanneer er in AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks opgestapeld zijn. BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van de straat, ook de opgegeven nummers op de tag van de script , 19 en 7, wijzen op niets. Dit heb ik al meermaals gespot. Voor de rest komt de script komt wel dik van pas. Groeten Sus Daarom dat er een kolom missing overlapping is. Die overlappende huisnummers liggen toch in die overlapping kolom? Of is er daar een fout mee? Die kolom is moeilijk om te behandelen, omdat het aan de mapper is om te beslissen als die meerdere huisnummers nu net samen horen, of gesplitst moeten worden over meerdere huizen. Door het in een aparte kolom te zetten kan je die moeilijkere gevallen houden voor later. Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Op 8-nov.-2014 23:07 schreef Jo winfi...@gmail.com: Sander, Ik denk dat die addr:official_housenumber op 1 node een betere oplossing is dan al die nodes bovenop elkaar. In het begin was er ook een veld met daarin 20-28. Was dat gegenereerd, of zit dat ook ergens zo in de CRAB-data? Als je de crab info aanvinkt zal je dat veld opnieuw hebben. Dat is het huisnummerlabel veld, en toont gewoon welke nummers aan hetzelfde grb object gelinkt zijn. Dus als er 2 ingangen zijn, en de data in crab is precies tot op de voordeur, dan zullen de nodes op andere posities staan, maar ze horen wel op hetzelfde gebouw en kunnen eventueel zo getagged worden in osm. Langs de andere kant ken ik een nieuwe staat, waar de huisnummers nog niet aan gebouwen gelinkt zijn, en waar dus alle 20 huisnummers overlappen met als label 1-20. Omdat ik vanop afstand niet kan weten welke nummers nu zichtbaar zijn en welke niet, kan ik ook de tag addr:official_housenumber niet meegeven. Het enige waar die tag voor gebruikt kan worden, is als een mapper niet graag onbestaande huisnummers wil mappen, maar toch de info van het crab zo goed mogelijk in osm wil krijgen. Sus, we zitten nog maar in de testfase en dat probleem van samengevoegde huizen en gebouwen met meerdere huisnummers, is een lastige noot om te kraken. Op de hoek van de Kapucijnenvoer met de Brusselsestraat, zag ik daarnet ook een blok waarvan elke winkel een apart huisnummer heeft, maar het is wel slechts 1 gebouw. Dat opdelen in smalle appartementsblokken, klopt niet, anderzijds zou het wel interessant zijn om aan te geven welk gedeelte van het gelijkvloers elke winkel inneemt In het gebouw aan het Mercatorpad zitten meerdere bedrijven. Ze staan daar nu als aparte nodes, zonder adresinformatie. Het is, met enkel OSM-data, niet mogelijk om te achterhalen welk adres bij welk bedrijf hoort. Sommige hebben hetzelfde huisnummer en een verschillend busnummer, wat betekent dat als de adressen herhaald worden op de nodes, dat een adres/huisnummer dan meerdere malen terugkomt. Dat gebouw opdelen zou een oplossing kunnen zijn, maar waar zou je dan splitsen? Nog even en we hebben de bouwplannen ook nog nodig :-) Ik heb het mappen ervan uitgesteld tot 'k 's ter plaatse kan gaan kijken, maar ik ben niet overtuigd dat ik dan wel zal weten hoe het te mappen. Jo Op 8 november 2014 11:54 schreef Sander Deryckere sander...@gmail.com: @Glenn: Ik begrijp niet goed wat je wil zeggen. Door ze als addr:official_housenumber te taggen gaan ze net extra bovenkomen (met overpass kan je bijvoorbeeld eenvoudig zoeken waar die liggen). Een goeie geocoder (die in tegenstelling tot Nominatim ook goed werkt met Belgische adressen) zou het onderscheid kunnen maken tussen beiden, maar de geocoder kan ze ook door elkaar gebruiken als dat wenselijk is. Dus ben je nu voor of tegen die official_housenumber tag? Op 8 november 2014 09:58 schreef Verhoeven Fr sus...@gmail.com: Dag Sander, Met de script krijgt men soms opgestapelde huisnummers wanneer er in AGIV GRB een huis is met 2 nummers of op de huizen die in een reeks opgestapeld zijn. BV. 3970, Sint Antoniusstraat, 9-21 en 7-23 (in GRB) in het begin van de straat, ook de opgegeven nummers op de tag van de script , 19 en 7, wijzen op niets. Dit heb ik al meermaals gespot. Voor de rest komt de script komt wel dik van pas. Groeten Sus Daarom dat er een kolom missing overlapping is. Die overlappende huisnummers liggen toch in die overlapping kolom? Of is er daar een fout mee? Die kolom is moeilijk om te behandelen, omdat het aan de mapper is om te beslissen als die meerdere huisnummers nu net samen horen, of gesplitst moeten worden over meerdere huizen. Door het in een aparte kolom te zetten kan je die moeilijkere gevallen houden voor later. Voor die huisnummers die niet op een gebouw wijzen (en dus niet in realiteit zichtbaar zijn) stel ik net addr:official_housenumber voor. Vind je dat een goede tag of niet? Groeten, Sander ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb ontdekt dat het CRAB blijkbaar vaak huisnummers heeft die in het echt niet zichtbaar zijn. Daaronder vallen de eerder genoemde percelen die genummerd zijn (zonder gebouw), maar soms krijgt 1 huis ook meerdere nummers, terwijl er van buiten maar 1 zichtbaar is (en er eigenlijk maar 1 gebruikt wordt). Om die gevallen op te vangen stel ik een addr:official_housenumber voor. Officiële huisnummers zijn de huisnummers zoals die in het CRAB zitten, maar niet zichtbaar zijn. Het voordeel van die tag wordt zichtbaar bij het geocoden en reverse-geocoden. Als je de positie (en het huis) weet, en je vraagt het adres van dat huis, dan zal je enkel met het zichtbare huisnummer geconfronteerd worden. Als je het adres weet, en je zoekt het huis, dan kan je zowel op puur officiële als op zichtbare huisnummers zoeken. Ik denk dat dit onderscheid de kwaliteit van OSM zal helpen, en tegelijkertijd het aantal missing huisnummers verminderen, zonder dat één van de twee echt fundamenteel van idee over huisnummers moet veranderen. Als voorbeeld heb ik ook al een appartement zo getagged: http://www.openstreetmap.org/way/114659528 De tools zijn er al op voorbereid, wat denken jullie? Op 6 november 2014 22:51 schreef Jo winfi...@gmail.com: Wat die tips betreft, ik ben allerlei dingen aan het uitproberen in JOSM. Spijtig genoeg heb ik niet zo'n goede ervaringen met de Conflation plugin. Die crasht bij mij nogal gemakkelijk. Ik ben nu zelf een scriptje aan het ontwikkelen. Het nadeel daarvan is natuurlijk dat iedereen die dat zou willen gebruiken de scripting plugin moet installeren + Jython. Verder helpt de UtilsPlugin2 met z'n Select All Inside en dan Replace Geometry. Ik heb die wel op andere sneltoetsen gezet, zodat ze vlotter bereikbaar zijn. Gebouw aanklikken, 't' selecteert dan de CRAB-node erbij (als die binnen de contour ligt toch), dan 'v' om de tags van de ene op de andere over te zetten. Dat werkt vrij vlot en is wat m'n script ook doet in een eerste pass. Op plaatsen met rijtjeshuizen die nog niet gemapt zijn, komt de terracer plugin heel erg van pas. Rechthoek rondtekenen met de buildingstool 'b'. Indien nodig aanklikken om te selecteren, 't' om alle CRAB-nodes erbinnen te selecteren. Shift-klik op een hoeknode in de buurt van het laagste huisnummer, dan Shift-T om de terracer te starten. Wat echter het meeste tijd kost, is de huizen uitlijnen op de luchtfoto's en daar is niet veel aan te doen. Al die nodes verslepen, dat blijft tijdrovend. Het enige wat nog meer tijd vraagt is ter plaatse gaan nakijken hoe het zit met die appartementnummers :-) Jo Op 6 november 2014 18:23 schreef Sander Deryckere sander...@gmail.com: Ondertussen heb ik contact gehad met Jan Laporte van AGIV, en hij heeft mij één en ander verduidelijkt. Vooraleerst, het verschil tussen bus- en appartementsnumers is dat er in busnummers geen betekenis zit, terwijl er in appartementsnummers wel een betekenis zit (bijvoorbeeld, nummer 203 kan staan voor verdieping 2, kamer 3). Het is nooit de bedoeling dat zowel bus- als appartementsnummer voorkomen op hetzelfde gebouw, daarom denken ze er ook aan om dat onderscheid af te schaffen (wat voor mij geen probleem is). Ook het verschil tussen dubbele huisnummers (vb. 24-26), twee huisnummers op één huis, en de huisnummerlabels van het CRAB is nu wat duidelijker. bPost gebruikt dubbele huisnummers (of meervoudige huisnummers in het algemeen) gewoon als huisnummer. CRAB heeft daarentegen per huisnummer een apart object, dat aan hetzelfde gebouw gebonden wordt indien er sprake is van een dubbel huisnummer. De huisnummerlabels hangen daar maar ergens tussen, en het is niet omdat er een huisnummerlabel is, dat er ook dubbele huisnummers zijn. Als gevolg heb ik er nu voor gekozen om het huisnummerlabel niet meer te gebruiken, en in plaats daarvan, ranges in OSM huisnummers te expanden (dus 22-26 matcht met 22, 24 en 26). Dat zorgt voor wat nieuwe, fragiele code, dus testers zijn steeds welkom. Daarnaast heeft Jan mij ook gewezen op het proces om fouten te melden, wat ik ook op de wiki gedocumenteerd heb: https://wiki.openstreetmap.org/wiki/NL:WikiProject_Belgium/Using_AGIV_Crab_data/Reporting_errors_to_AGIV De fouten worden behandeld door de gemeente, dus is de snelheid van behandeling ook afhankelijk van je gemeente. Net zoals de foute postcodes (die buiten de gemeentegrenzen vallen), die moeten ook door de gemeenten opgelost worden, en dat tegen juni 2015. Ook over welke fouten moeten gemeld worden heeft Jan wat inzicht gegeven, die zal ik later nog documenteren op de wiki. Iedereen is natuurlijk welkom om te helpen met die documentatie (vooral tips om snel te mappen zijn welkom), zodat we een degelijk referentiedocument hebben. Ook het testen van de tools is steeds welkom. @Thomas: hoe zit het met je conversiescript? De output is voor mij al goed genoeg in ieder geval, en ik zou er graag eens naar kijken. Als je het script
Re: [OSM-talk-be] import AGIV CRAB-data
Ik had altijd begrepen dat je een huisnummer ook aan een perceel kan toewijzen. o.a. voor die braakliggende terreinen, maar bijv. ook voor scholen met meerdere gebouwen of sites waar meerdere industriële gebouwen hetzelfde adres hebben. Dus voor die braakliggende terreinen, kan het huidige grondgebruik, bv meadow of greenfield of brownfield (als er iets werd afgebroken, zodat het braak kwam te liggen) voorzien van dat huisnummer. Huisnummers/adressen blijven rare dingen. Ze betekenen iets anders voor het kadaster dan voor de post en nog iets anders voor iemand die de voordeur/toegang tot voortuin zoekt, al dan niet slechtziend of blind. Onlangs ben ik in de Balk van Beel langs de verkeerde deur binnengegaan. Daar hebben ze een afzonderlijk afleverpunt voor pakjes, Een deurbel vind je daar echter niet... Nogal verwarrend, want je vind daar wel al die huisnummers en een paneel met knopjes, maar aanbellen lukt niet. Zo'n voorziening is natuurlijk uitzonderlijk, maar eigenlijk zouden we dat ook moeten kunnen mappen. (Voor die transporteurs die die pakjes komen leveren :-) Jo Op 7 november 2014 22:16 schreef Glenn Plas gl...@byte-consult.be: Nu ik mapte ondertussen al gewoon een node op die braakliggende stukken met een toegewezen nummer, eentje met addr:street ook. Ik vroeg me af of het nut had, het zijn echte nummers die bestaan. Wel handig voor grond te kopen/verkopen bv. Dus ik zou liever hebben dat die wel voor alles officiel in aanmerking komen (map/geocode etc) Ik vind het dus net goed dat ze boven komen, met de bedenking dat in het osm model een nummer aan een gebouw toehoort als ik me niet vergis. Die ongebruikte nummers liet ik zo. Glenn On 07-11-14 16:55, Marc Gemis wrote: Begrijp ik het goed dat in CRAB 22-26 staat, op straat 22 ? Dus je herhaalt het zichtbare nummer niet in addr:official_housenumber ? voor mij is het prima hoor, maakt me niet uit. 2014-11-07 16:16 GMT+01:00 Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: Ik heb ontdekt dat het CRAB blijkbaar vaak huisnummers heeft die in het echt niet zichtbaar zijn. Daaronder vallen de eerder genoemde percelen die genummerd zijn (zonder gebouw), maar soms krijgt 1 huis ook meerdere nummers, terwijl er van buiten maar 1 zichtbaar is (en er eigenlijk maar 1 gebruikt wordt). Om die gevallen op te vangen stel ik een addr:official_housenumber voor. Officiële huisnummers zijn de huisnummers zoals die in het CRAB zitten, maar niet zichtbaar zijn. Het voordeel van die tag wordt zichtbaar bij het geocoden en reverse-geocoden. Als je de positie (en het huis) weet, en je vraagt het adres van dat huis, dan zal je enkel met het zichtbare huisnummer geconfronteerd worden. Als je het adres weet, en je zoekt het huis, dan kan je zowel op puur officiële als op zichtbare huisnummers zoeken. Ik denk dat dit onderscheid de kwaliteit van OSM zal helpen, en tegelijkertijd het aantal missing huisnummers verminderen, zonder dat één van de twee echt fundamenteel van idee over huisnummers moet veranderen. Als voorbeeld heb ik ook al een appartement zo getagged: http://www.openstreetmap.org/way/114659528 De tools zijn er al op voorbereid, wat denken jullie? Op 6 november 2014 22:51 schreef Jo winfi...@gmail.com mailto:winfi...@gmail.com: Wat die tips betreft, ik ben allerlei dingen aan het uitproberen in JOSM. Spijtig genoeg heb ik niet zo'n goede ervaringen met de Conflation plugin. Die crasht bij mij nogal gemakkelijk. Ik ben nu zelf een scriptje aan het ontwikkelen. Het nadeel daarvan is natuurlijk dat iedereen die dat zou willen gebruiken de scripting plugin moet installeren + Jython. Verder helpt de UtilsPlugin2 met z'n Select All Inside en dan Replace Geometry. Ik heb die wel op andere sneltoetsen gezet, zodat ze vlotter bereikbaar zijn. Gebouw aanklikken, 't' selecteert dan de CRAB-node erbij (als die binnen de contour ligt toch), dan 'v' om de tags van de ene op de andere over te zetten. Dat werkt vrij vlot en is wat m'n script ook doet in een eerste pass. Op plaatsen met rijtjeshuizen die nog niet gemapt zijn, komt de terracer plugin heel erg van pas. Rechthoek rondtekenen met de buildingstool 'b'. Indien nodig aanklikken om te selecteren, 't' om alle CRAB-nodes erbinnen te selecteren. Shift-klik op een hoeknode in de buurt van het laagste huisnummer, dan Shift-T om de terracer te starten. Wat echter het meeste tijd kost, is de huizen uitlijnen op de luchtfoto's en daar is niet veel aan te doen. Al die nodes verslepen, dat blijft tijdrovend. Het enige wat nog meer tijd vraagt is ter plaatse gaan nakijken hoe het zit
Re: [OSM-talk-be] import AGIV CRAB-data
Je kan voor de deur voor leveranciers de tag entrance=service gebruiken. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ondertussen heb ik contact gehad met Jan Laporte van AGIV, en hij heeft mij één en ander verduidelijkt. Vooraleerst, het verschil tussen bus- en appartementsnumers is dat er in busnummers geen betekenis zit, terwijl er in appartementsnummers wel een betekenis zit (bijvoorbeeld, nummer 203 kan staan voor verdieping 2, kamer 3). Het is nooit de bedoeling dat zowel bus- als appartementsnummer voorkomen op hetzelfde gebouw, daarom denken ze er ook aan om dat onderscheid af te schaffen (wat voor mij geen probleem is). Ook het verschil tussen dubbele huisnummers (vb. 24-26), twee huisnummers op één huis, en de huisnummerlabels van het CRAB is nu wat duidelijker. bPost gebruikt dubbele huisnummers (of meervoudige huisnummers in het algemeen) gewoon als huisnummer. CRAB heeft daarentegen per huisnummer een apart object, dat aan hetzelfde gebouw gebonden wordt indien er sprake is van een dubbel huisnummer. De huisnummerlabels hangen daar maar ergens tussen, en het is niet omdat er een huisnummerlabel is, dat er ook dubbele huisnummers zijn. Als gevolg heb ik er nu voor gekozen om het huisnummerlabel niet meer te gebruiken, en in plaats daarvan, ranges in OSM huisnummers te expanden (dus 22-26 matcht met 22, 24 en 26). Dat zorgt voor wat nieuwe, fragiele code, dus testers zijn steeds welkom. Daarnaast heeft Jan mij ook gewezen op het proces om fouten te melden, wat ik ook op de wiki gedocumenteerd heb: https://wiki.openstreetmap.org/wiki/NL:WikiProject_Belgium/Using_AGIV_Crab_data/Reporting_errors_to_AGIV De fouten worden behandeld door de gemeente, dus is de snelheid van behandeling ook afhankelijk van je gemeente. Net zoals de foute postcodes (die buiten de gemeentegrenzen vallen), die moeten ook door de gemeenten opgelost worden, en dat tegen juni 2015. Ook over welke fouten moeten gemeld worden heeft Jan wat inzicht gegeven, die zal ik later nog documenteren op de wiki. Iedereen is natuurlijk welkom om te helpen met die documentatie (vooral tips om snel te mappen zijn welkom), zodat we een degelijk referentiedocument hebben. Ook het testen van de tools is steeds welkom. @Thomas: hoe zit het met je conversiescript? De output is voor mij al goed genoeg in ieder geval, en ik zou er graag eens naar kijken. Als je het script publiceert, en we krijgen de documentatie geschreven, dan kan het naar de import lijst voor goedkeuring denk ik. Groeten, Sander Op 4 november 2014 11:59 schreef Jo winfi...@gmail.com: Het kan geen kwaad dat het script nu wat robuuster is. Het geeft wel aan hoe nuttig die Overpass API is, maar ook hoe afhankelijk we er van geworden zijn. Ik kan ook niet uit de voeten met de Franse of de Russische instances. Ik zal 's moeten nakijken wat voor speciale zaken ik dan wel gebruik in m'n query. Maar het zou ook gewoon een timeoutprobleem kunnen zijn. Size:148053763 Compressed: 16914097 Er wordt nogal veel data opgehaald. Eigenlijk een klein wonder dat zoiets mogelijk is. Jo Op 4 november 2014 11:06 schreef Sander Deryckere sander...@gmail.com: En natuurlijk is net nu Overpass terug online. Het script gebruikt nu opnieuw de Duitse versie, dus moet alles terug werken. Op 4 november 2014 08:49 schreef Sander Deryckere sander...@gmail.com: CRAB gebruikt idd enkel de gemeentenaam, en dat is ook de voorkeur van de Post. Dit is nog maar eens een argument voor goede grenzen. Een punt ligt binnen de grens van Leuven (met admin_level=8) en binnen de postcode grens van 3018. Dus kan je het adres 3018 Leuven afleiden. Het ligt ook binnen de grens van Wijgmaal (met admin_level=9), dus kan je even goed 3018 Wijgmaal afleiden. Als je de naam van de postcode-zone wilt (i.p.v. altijd de gemeente of altijd de deelgemeente), dan kan je die ook gebruiken, want die is ook getagged op de postcode grens. Zo laat je de keuze aan de data gebruikers over hoe ze het adres noteren. Vroeger heb ik zelfs de naam van mijn deelgemeente (zonder aparte postcode) als addr:city getagged. Dat ben ik nu ook aan het verwijderen waar ik de adressen controleer en verbeter. Aangezien de overpass emergency rollback langer duurt dan gedacht heb ik ook wat aan het script geprutst. Alles dat geen posities van OSM nodig heeft werkt nu. Dat is dus alles uitgezonderd de afstandsvergelijking (die de twee posities moet vergelijken) en de wrong kolom (die aangeeft waar in OSM er een fout is). Het zou ook moeten blijven werken als we weer naar de nieuwere API overschakelen. Groeten, Sander Op 4 november 2014 00:13 schreef Johan Van de Wauw johan.vandew...@gmail.com: 2014-11-04 0:07 GMT+01:00 Jo winfi...@gmail.com: Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is? Jo Er is allessinds geen officieel bestand dat aangeeft tot waar Wijgmaal loopt. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
En natuurlijk is net nu Overpass terug online. Het script gebruikt nu opnieuw de Duitse versie, dus moet alles terug werken. Op 4 november 2014 08:49 schreef Sander Deryckere sander...@gmail.com: CRAB gebruikt idd enkel de gemeentenaam, en dat is ook de voorkeur van de Post. Dit is nog maar eens een argument voor goede grenzen. Een punt ligt binnen de grens van Leuven (met admin_level=8) en binnen de postcode grens van 3018. Dus kan je het adres 3018 Leuven afleiden. Het ligt ook binnen de grens van Wijgmaal (met admin_level=9), dus kan je even goed 3018 Wijgmaal afleiden. Als je de naam van de postcode-zone wilt (i.p.v. altijd de gemeente of altijd de deelgemeente), dan kan je die ook gebruiken, want die is ook getagged op de postcode grens. Zo laat je de keuze aan de data gebruikers over hoe ze het adres noteren. Vroeger heb ik zelfs de naam van mijn deelgemeente (zonder aparte postcode) als addr:city getagged. Dat ben ik nu ook aan het verwijderen waar ik de adressen controleer en verbeter. Aangezien de overpass emergency rollback langer duurt dan gedacht heb ik ook wat aan het script geprutst. Alles dat geen posities van OSM nodig heeft werkt nu. Dat is dus alles uitgezonderd de afstandsvergelijking (die de twee posities moet vergelijken) en de wrong kolom (die aangeeft waar in OSM er een fout is). Het zou ook moeten blijven werken als we weer naar de nieuwere API overschakelen. Groeten, Sander Op 4 november 2014 00:13 schreef Johan Van de Wauw johan.vandew...@gmail.com: 2014-11-04 0:07 GMT+01:00 Jo winfi...@gmail.com: Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is? Jo Er is allessinds geen officieel bestand dat aangeeft tot waar Wijgmaal loopt. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Het kan geen kwaad dat het script nu wat robuuster is. Het geeft wel aan hoe nuttig die Overpass API is, maar ook hoe afhankelijk we er van geworden zijn. Ik kan ook niet uit de voeten met de Franse of de Russische instances. Ik zal 's moeten nakijken wat voor speciale zaken ik dan wel gebruik in m'n query. Maar het zou ook gewoon een timeoutprobleem kunnen zijn. Size:148053763 Compressed: 16914097 Er wordt nogal veel data opgehaald. Eigenlijk een klein wonder dat zoiets mogelijk is. Jo Op 4 november 2014 11:06 schreef Sander Deryckere sander...@gmail.com: En natuurlijk is net nu Overpass terug online. Het script gebruikt nu opnieuw de Duitse versie, dus moet alles terug werken. Op 4 november 2014 08:49 schreef Sander Deryckere sander...@gmail.com: CRAB gebruikt idd enkel de gemeentenaam, en dat is ook de voorkeur van de Post. Dit is nog maar eens een argument voor goede grenzen. Een punt ligt binnen de grens van Leuven (met admin_level=8) en binnen de postcode grens van 3018. Dus kan je het adres 3018 Leuven afleiden. Het ligt ook binnen de grens van Wijgmaal (met admin_level=9), dus kan je even goed 3018 Wijgmaal afleiden. Als je de naam van de postcode-zone wilt (i.p.v. altijd de gemeente of altijd de deelgemeente), dan kan je die ook gebruiken, want die is ook getagged op de postcode grens. Zo laat je de keuze aan de data gebruikers over hoe ze het adres noteren. Vroeger heb ik zelfs de naam van mijn deelgemeente (zonder aparte postcode) als addr:city getagged. Dat ben ik nu ook aan het verwijderen waar ik de adressen controleer en verbeter. Aangezien de overpass emergency rollback langer duurt dan gedacht heb ik ook wat aan het script geprutst. Alles dat geen posities van OSM nodig heeft werkt nu. Dat is dus alles uitgezonderd de afstandsvergelijking (die de twee posities moet vergelijken) en de wrong kolom (die aangeeft waar in OSM er een fout is). Het zou ook moeten blijven werken als we weer naar de nieuwere API overschakelen. Groeten, Sander Op 4 november 2014 00:13 schreef Johan Van de Wauw johan.vandew...@gmail.com: 2014-11-04 0:07 GMT+01:00 Jo winfi...@gmail.com: Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is? Jo Er is allessinds geen officieel bestand dat aangeeft tot waar Wijgmaal loopt. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de http://overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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
Re: [OSM-talk-be] import AGIV CRAB-data
Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Met gezipte antwoorden kan JS niet overweg. Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer werkt, of de Russische versie hun software heeft geupdated. De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren heeft volgens mij geen zin. Groeten, Sander Op 3 november 2014 15:46 schreef Jo winfi...@gmail.com: Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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 ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel voor een lookuptabel. Jo Op 3 november 2014 15:58 schreef Sander Deryckere sander...@gmail.com: Met gezipte antwoorden kan JS niet overweg. Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer werkt, of de Russische versie hun software heeft geupdated. De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren heeft volgens mij geen zin. Groeten, Sander Op 3 november 2014 15:46 schreef Jo winfi...@gmail.com: Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing listTalk-be@openstreetmap.orghttps://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 ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Die gemeentenaam komt uit de CRAB-data. Ik denk dat dat losstaat van de Overpass Query. Jo Op 3 november 2014 23:59 schreef Glenn Plas gl...@byte-consult.be: Ik zou het nu niet gebruiken, de Russische data komt niet goed. Als de duitse overpass api terug goed werkt zal het beter gaan. Ik had alles in 1982 goed gezet, en ik krijg andere resultaten nu. Glenn On 03-11-14 23:48, Jo wrote: Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel voor een lookuptabel. Jo Op 3 november 2014 15:58 schreef Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: Met gezipte antwoorden kan JS niet overweg. Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer werkt, of de Russische versie hun software heeft geupdated. De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren heeft volgens mij geen zin. Groeten, Sander Op 3 november 2014 15:46 schreef Jo winfi...@gmail.com mailto:winfi...@gmail.com: Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com mailto:winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl mailto:o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de http://overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle
Re: [OSM-talk-be] import AGIV CRAB-data
3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente, niet Kessel-Lo. http://www.bpost.be/adressering/#2 • Gebruik bij voorkeur de naam van de fusiegemeente (die van uw gemeentehuis). 2014-11-03 23:48 GMT+01:00 Jo winfi...@gmail.com: Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel voor een lookuptabel. Jo Op 3 november 2014 15:58 schreef Sander Deryckere sander...@gmail.com: Met gezipte antwoorden kan JS niet overweg. Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer werkt, of de Russische versie hun software heeft geupdated. De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren heeft volgens mij geen zin. Groeten, Sander Op 3 november 2014 15:46 schreef Jo winfi...@gmail.com: Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be: Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ 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 ___ 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 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is? Jo Op 4 november 2014 00:04 schreef Johan Van de Wauw johan.vandew...@gmail.com: 3010 Leuven is de enige correcte schrijfwijze: Leuven is de gemeente, niet Kessel-Lo. http://www.bpost.be/adressering/#2 • Gebruik bij voorkeur de naam van de fusiegemeente (die van uw gemeentehuis). 2014-11-03 23:48 GMT+01:00 Jo winfi...@gmail.com: Ik heb 's een straat in 3010 Kessel-Lo afgehaald. Vreemd genoeg komt daar nu addr:city=Leuven uit. Zitten de deelgemeentes ook in de data van CRAB? Ik vind 3010 of 3012 Leuven ipv Kessel-Lo/Wilsele niet bepaald logisch. Al weet ik wel dat je dat wat De Post betreft ook zo mag schrijven. Als het zo niet in CRAB zit en wij geraken het erover eens dat we de deelgemeentes in de adressen willen gebruiken, dan zorg ik wel voor een lookuptabel. Jo Op 3 november 2014 15:58 schreef Sander Deryckere sander...@gmail.com: Met gezipte antwoorden kan JS niet overweg. Ik denk dat er niets anders op zit dan te wachten tot de Duitse versie weer werkt, of de Russische versie hun software heeft geupdated. De code wijzigen voor de (hopelijk) enkele dagen dat dit ongemak zal duren heeft volgens mij geen zin. Groeten, Sander Op 3 november 2014 15:46 schreef Jo winfi...@gmail.com: Dit is het volledige adres: http://oapi-fr.openstreetmap.fr/oapi/interpreter Die geeft wel steeds een gezipt antwoord, blijkbaar. En mijn query voor alles wat met openbaar vervoer te maken heeft in België kan hij niet aan. jo Op 3 november 2014 12:46 schreef Jo winfi...@gmail.com: Misschien 's op de Franse server proberen: http://oapi-fr.openstreetmap.fr/oapi Jo Op 3 november 2014 10:24 schreef Sander Deryckere sander...@gmail.com: Wel, ik gebruik de out center abstractie van overpass (het bespaart me de moeite om zelf de centra te berekenen, en het bespaart bandbreedte), en die feature is nog maar enkele maanden uit. Dus misschien ontbreekt die nog op de Russische versie. Groeten, Sander Op 3-nov.-2014 09:39 schreef Thomas o...@aptum.nl: Dat vind ik ook zeer opvallend. Ik heb me alleen helemaal niet bezig gehouden met de ontwikkeling van het javascript-gedeelte van de website. Op dit moment kan ik de Russische output ook moeilijk vergelijken met de Duitse, aangezien die Duitse het niet doet. Overigens; die doet het nog steeds niet. Dat soort emergency-ingrepen duren toch vaak langer dan men verwacht. Van zodra hij terug online is ga ik de verschillen even nader bestuderen. Groeten, Thomas Jo schreef op 3-11-2014 9:32: Op zich is het wel vreemd dat die 2 instances van Overpass niet dezelfde output teruggeven. Het gaat om dezelfde code. Al is de Duitse over het algemeen sneller met het aanbieden van nieuwe features. Misschien is het toch wel nodig om te melden dat de json-output afwijkt. mvg, Jo Op 3 november 2014 08:56 schreef Glenn Plas gl...@byte-consult.be : Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ 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 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org
Re: [OSM-talk-be] import AGIV CRAB-data
2014-11-04 0:07 GMT+01:00 Jo winfi...@gmail.com: Wat De Post betreft dus wel, ja. Weet jij waar 3018 Leuven is? Jo Er is allessinds geen officieel bestand dat aangeeft tot waar Wijgmaal loopt. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Sander,
Ik heb de JSON-bestanden opnieuw aangemaakt met apptnrs en busnrs, deze
keer als echte arrays. Ik zie dat je precies nu bezig bent met wat
wijzigingen. Daarom even acties op elkaar afstemmen om geen conflicten
te veroorzaken. Laat je weten als je een uur geen push zult doen? Dan
pull-commit-push ik de nieuwe JSON bestanden op dat moment.
Groeten,
Thomas
Sander Deryckere schreef op 1-11-2014 21:45:
Thomas,
In je spec staat dat busnummers en appartementnummers arrays zijn,
maar in werkelijkheid lijken het comma-separated strings. Zou je het
kunnen wijzigen naar arrays? Arrays lijken veiliger voor het geval een
busnummer plots ook een komma bevat.
Verder zijn er idd eigenaardige adressen. Dit zijn er twee in mijn dorp:
{
apptnrs: 0/1,0/2,1/1,1/2,1/3,2/1,2/2,2/3,3/1,3/2,
busnrs: 1,11,3,
hnrlbls: [
22-26
],
housenumber: 22,
lat: 50.94126031777649,
lon: 3.061661179477891,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
Let op, nr 22 heeft hier veel bus- en appartementsnummers, nummer 26
blijkt er geen te hebben.
{
apptnrs: 0/1,1/3,2/1,2/2,2/3,3/3,
busnrs: 1,2,
hnrlbls: [
7
],
housenumber: 7,
lat: 50.94025949900766,
lon: 3.060482929425432,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
In beide gevallen lijkt er totaal geen verband tussen de busnummers en
appartementsnummers te bestaan. Ik zal morgen of overmorgen eens
bekijken wat er daar nu net zichtbaar is.
Momenteel zal ik dus nog geen toevoegen aan de uitvoer. Iedereen die
meer info kan geven is zeker welkom.
Groeten,
Sander
Op 1 november 2014 20:43 schreef Thomas o...@aptum.nl
mailto:o...@aptum.nl:
Het gebeurt in totaal 702 keer over alle adressen (inclusief
subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27
oktober mailde ik dit daarover:
Verder is er iets bijzonder aan de hand met de
huisnummer-labels. Die worden door het AGIV automatisch opgemaakt
per huisnummer, althans, zo hoort het. Toch heb ik met een check
in mijn script 702 afwijkende huisnummerlabels weten te vinden.
Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar
tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht
genomen dat 67% van die afwijkende huisnummerlabels zich voordoen
in postcode 8900 lijkt het mij om een fout in de database te gaan.
Wat er precies fout gelopen is op die punten weet ik niet. Ik heb
de lijst op mijn server geplaatst:
http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf
In dat pdf-document krijg je een overzicht van huisnummer-labels
die niet systematisch gelijk zijn voor alle subadressen voor dat
huisnummer. Meestal lijkt het om vrij logische fouten te gaan.
Hoe het kan dat dit niet consistent is in de CRAB-adressenlijst is
mij niet duidelijk. Ik heb het gevoel dat het om een
versie-probleempje gaat, dat niet alle huisnummers systematisch
worden bijgewerkt wanneer een subadres wordt toegevoegd of wordt
verwijderd. Omdat ik geen verder onderscheid kon maken tussen
goede en foute huisnummers leek het mij het beste om ze gewoon
allemaal mee te geven in de JSON.
Groeten,
Thomas
Sander Deryckere schreef op 1-11-2014 20:15:
Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl
mailto:o...@aptum.nl:
Zoals eerder gezegd is de voornaamste wijziging die invloed
heeft op de huidige werking het feit dat huisnummerlabels nu
in een array meegegeven worden, zodat bij meerdere
huisnummer-labels per huisnummer, deze allemaal doorgegeven
kunnen worden. Dat kan Sander misschien helpen bij het
matchen met de gegevens uit OSM.
Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit
gebeurt. Ik weet niet goed hoe ik foute data kan vergelijken,
buiten melden dat er ergens een fout zit. Zal het verder onderzoeken.
___
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
Re: [OSM-talk-be] import AGIV CRAB-data
Wat die appartement en busnummers betreft, ik heb ook al gevallen gezien
waar het niet eenvoudig is om die te matchen. Zou het kunnen dat het
appartementnummer is, wat er op de bel staat en het busnummer wat je als
uitbreiding van het huisnummer op een enveloppe zou schrijven?
Dat zou dan betekenen dat iemand die dat wil nakijken met een survey,
gemakkelijker toegang zal hebben tot die appartementnummers. Misschien
kunnen we er de voorkeur aan geven om de appartementnummers in addr:flats
onder te brengen. Als beide er zijn de busnummers dan in een discardable
tag, ter referentie.
Als er geen appartementnummmers zijn, kunnen we natuurlijk gewoon de
gesorteerde busnummers in addr:flats onderbrengen.
Wat voor mij nog een twijfelgeval is, is wanneer er slechts 1 bus of
appartementnummer vermeld staat. Ik ben geneigd om dat dan niet mee over te
nemen.
Jo
Op 2 november 2014 09:41 schreef Sander Deryckere sander...@gmail.com:
Net mijn laatste wijzigingen gepushed. Zal in de volgende uren geen push
meer uitvoeren.
Zou je ook de wijzigingen aan loadStreets.js in een aparte comit kunnen
steken? Dan is het eenvoudiger om de diff te bekijken.
Groeten,
Sander
Op 2 november 2014 09:33 schreef Thomas o...@aptum.nl:
Sander,
Ik heb de JSON-bestanden opnieuw aangemaakt met apptnrs en busnrs, deze
keer als echte arrays. Ik zie dat je precies nu bezig bent met wat
wijzigingen. Daarom even acties op elkaar afstemmen om geen conflicten te
veroorzaken. Laat je weten als je een uur geen push zult doen? Dan
pull-commit-push ik de nieuwe JSON bestanden op dat moment.
Groeten,
Thomas
Sander Deryckere schreef op 1-11-2014 21:45:
Thomas,
In je spec staat dat busnummers en appartementnummers arrays zijn, maar
in werkelijkheid lijken het comma-separated strings. Zou je het kunnen
wijzigen naar arrays? Arrays lijken veiliger voor het geval een busnummer
plots ook een komma bevat.
Verder zijn er idd eigenaardige adressen. Dit zijn er twee in mijn dorp:
{
apptnrs: 0/1,0/2,1/1,1/2,1/3,2/1,2/2,2/3,3/1,3/2,
busnrs: 1,11,3,
hnrlbls: [
22-26
],
housenumber: 22,
lat: 50.94126031777649,
lon: 3.061661179477891,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
Let op, nr 22 heeft hier veel bus- en appartementsnummers, nummer 26
blijkt er geen te hebben.
{
apptnrs: 0/1,1/3,2/1,2/2,2/3,3/3,
busnrs: 1,2,
hnrlbls: [
7
],
housenumber: 7,
lat: 50.94025949900766,
lon: 3.060482929425432,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
In beide gevallen lijkt er totaal geen verband tussen de busnummers en
appartementsnummers te bestaan. Ik zal morgen of overmorgen eens bekijken
wat er daar nu net zichtbaar is.
Momenteel zal ik dus nog geen toevoegen aan de uitvoer. Iedereen die
meer info kan geven is zeker welkom.
Groeten,
Sander
Op 1 november 2014 20:43 schreef Thomas o...@aptum.nl:
Het gebeurt in totaal 702 keer over alle adressen (inclusief
subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27 oktober
mailde ik dit daarover:
Verder is er iets bijzonder aan de hand met de huisnummer-labels.
Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo
hoort het. Toch heb ik met een check in mijn script 702 afwijkende
huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat
natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal.
Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich
voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan.
Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst
op mijn server geplaatst:
http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf
In dat pdf-document krijg je een overzicht van huisnummer-labels die
niet systematisch gelijk zijn voor alle subadressen voor dat huisnummer.
Meestal lijkt het om vrij logische fouten te gaan. Hoe het kan dat dit
niet consistent is in de CRAB-adressenlijst is mij niet duidelijk. Ik heb
het gevoel dat het om een versie-probleempje gaat, dat niet alle
huisnummers systematisch worden bijgewerkt wanneer een subadres wordt
toegevoegd of wordt verwijderd. Omdat ik geen verder onderscheid kon maken
tussen goede en foute huisnummers leek het mij het beste om ze gewoon
allemaal mee te geven in de JSON.
Groeten,
Thomas
Sander Deryckere schreef op 1-11-2014 20:15:
Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl:
Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op
de huidige werking het feit dat huisnummerlabels nu in een array meegegeven
worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal
doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het
Re: [OSM-talk-be] import AGIV CRAB-data
Heb nu postcode 1982 gedaan tot en met straten met een T*. Heel veel werkt, mijn RSI-pols is terug maar we zijn er bijna erdoor. Er vallen mij wel aantal dingen op. -1A vs 1a wordt door de tool als fout gemerkt, niet echt een probleem, ik zet ze allemaal naar de hoofdletter versie, mss wel goed dat het uniform is. - CRab data voor 1982 is niet slecht meestal. Ik vind niet veel fouten eigenlijk tot hiertoe, meeste zijn twijfelaars ivm subaddressen - Indien CRAB enkel officiele nummer vermeld (ik weet hier een 3-woonst die enkel onder nummer 1 gekend is hier). Maar ik heb er persoonlijk een survey gedaan, dus 1/1,2,3 bestaan. Dat zet ik onder addr:flats indien gemeenschappelijke ingang. Gaat prima tot hiertoe. Geen noemenswaardige issues. Glenn On 02-11-14 10:56, Jo wrote: Wat die appartement en busnummers betreft, ik heb ook al gevallen gezien waar het niet eenvoudig is om die te matchen. Zou het kunnen dat het appartementnummer is, wat er op de bel staat en het busnummer wat je als uitbreiding van het huisnummer op een enveloppe zou schrijven? Dat zou dan betekenen dat iemand die dat wil nakijken met een survey, gemakkelijker toegang zal hebben tot die appartementnummers. Misschien kunnen we er de voorkeur aan geven om de appartementnummers in addr:flats onder te brengen. Als beide er zijn de busnummers dan in een discardable tag, ter referentie. Als er geen appartementnummmers zijn, kunnen we natuurlijk gewoon de gesorteerde busnummers in addr:flats onderbrengen. Wat voor mij nog een twijfelgeval is, is wanneer er slechts 1 bus of appartementnummer vermeld staat. Ik ben geneigd om dat dan niet mee over te nemen. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
De appartementnummers en busnummers zijn nu toegevoegd aan de tools. Er wordt ook gewaarschuwd indien zowel bus- als appartementsnummers aanwezig zijn. Wees nog voorzichtig met deze tag. Ik heb nog geen tijd gehad om uit te zoeken welke CRAB onderverdeling nu gebruikt wordt in welk geval. Ik heb ook een test toegevoegd die moet helpen om de huisnummers te standardiseren. Voor alles wat nu buiten het standaardformaat valt zal je een waarschuwing voor krijgen (bijvoorbeeld 10_2, wat 10 bis of 10/2 zou moeten zijn). Ik hoop dat er zo niet teveel vals-positieven gegenereerd worden. We kunnen altijd nog die test terug verwijderen of versoepelen. Groeten, Sander Op 2 november 2014 14:35 schreef Glenn Plas gl...@byte-consult.be: Heb nu postcode 1982 gedaan tot en met straten met een T*. Heel veel werkt, mijn RSI-pols is terug maar we zijn er bijna erdoor. Er vallen mij wel aantal dingen op. -1A vs 1a wordt door de tool als fout gemerkt, niet echt een probleem, ik zet ze allemaal naar de hoofdletter versie, mss wel goed dat het uniform is. - CRab data voor 1982 is niet slecht meestal. Ik vind niet veel fouten eigenlijk tot hiertoe, meeste zijn twijfelaars ivm subaddressen - Indien CRAB enkel officiele nummer vermeld (ik weet hier een 3-woonst die enkel onder nummer 1 gekend is hier). Maar ik heb er persoonlijk een survey gedaan, dus 1/1,2,3 bestaan. Dat zet ik onder addr:flats indien gemeenschappelijke ingang. Gaat prima tot hiertoe. Geen noemenswaardige issues. Glenn On 02-11-14 10:56, Jo wrote: Wat die appartement en busnummers betreft, ik heb ook al gevallen gezien waar het niet eenvoudig is om die te matchen. Zou het kunnen dat het appartementnummer is, wat er op de bel staat en het busnummer wat je als uitbreiding van het huisnummer op een enveloppe zou schrijven? Dat zou dan betekenen dat iemand die dat wil nakijken met een survey, gemakkelijker toegang zal hebben tot die appartementnummers. Misschien kunnen we er de voorkeur aan geven om de appartementnummers in addr:flats onder te brengen. Als beide er zijn de busnummers dan in een discardable tag, ter referentie. Als er geen appartementnummmers zijn, kunnen we natuurlijk gewoon de gesorteerde busnummers in addr:flats onderbrengen. Wat voor mij nog een twijfelgeval is, is wanneer er slechts 1 bus of appartementnummer vermeld staat. Ik ben geneigd om dat dan niet mee over te nemen. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
There's an error at the moment with the importer. loadStreets.js:276 Uncaught SyntaxError: Unexpected token import.html?pcode=1982filterStreets=*maxDistance=loadOsm=trueincludePcode=falsecrabInfo=false…:1 .. !-- vim: tabstop=2:softtabstop=2:shiftwidth=2:noexpandtab -- html This is on chrome. Glenn On 02-11-14 10:57, Thomas wrote: De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel netjes als array opgenomen en niet meer als comma-separated-string. Ik zag gisteren inderdaad dat het niet zo handig is om die mega-commit van die data-bestanden samen uit te voeren met wat losse wijzigingen in de code. Ik ga ze voortaan braaf in losse commits pushen ;-) Verder heb ik ook een doc-directory toegevoegd om de documentatie in te verzamelen. Daarin staan de documenten die ik eerder al op mijn server plaatste en ook een CSV-bestand met daarin de postcode-gemeentenaam probleemgevallen. Groeten, Thomas Sander Deryckere schreef op 2-11-2014 9:41: Net mijn laatste wijzigingen gepushed. Zal in de volgende uren geen push meer uitvoeren. Zou je ook de wijzigingen aan loadStreets.js in een aparte comit kunnen steken? Dan is het eenvoudiger om de diff te bekijken. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Groeten, Thomas Thomas schreef op 2-11-2014 23:43: Bedankt voor beide meldingen! Het probleem ligt in dit geval bij de overpass-api. De JSON-response bestaat niet uit JSON maar uit xhtml. Wanneer de javascript dat probeert te verwerken als een JSON-response treedt er een fout op. Dat heeft vast te maken met de emergency rollback waar je eerder over mailde. Ik heb even het request naar overpass.osm.rambler.ru doorgestuurd waardoor het request op zich nu weer werkt. Verderop in het script loopt nu wat verkeerd omdat het antwoord van deze Russische variant blijkbaar inhoudelijk verschillend is van de originele Duitse website. Ik kijk even of ik dat op kan lossen, anders draai ik het geheel terug naar de originele Duitse variant en moeten we maar even wachten tot de emergency rollback voorbij is. Groeten, Thomas Glenn Plas schreef op 2-11-2014 23:19: There's an error at the moment with the importer. loadStreets.js:276 Uncaught SyntaxError: Unexpected token import.html?pcode=1982filterStreets=*maxDistance=loadOsm=trueincludePcode=falsecrabInfo=false…:1 .. !-- vim: tabstop=2:softtabstop=2:shiftwidth=2:noexpandtab -- html This is on chrome. Glenn On 02-11-14 10:57, Thomas wrote: De nieuwe JSON-bestanden staan online. Nu zijn de busnrs en apptnrs wel netjes als array opgenomen en niet meer als comma-separated-string. Ik zag gisteren inderdaad dat het niet zo handig is om die mega-commit van die data-bestanden samen uit te voeren met wat losse wijzigingen in de code. Ik ga ze voortaan braaf in losse commits pushen ;-) Verder heb ik ook een doc-directory toegevoegd om de documentatie in te verzamelen. Daarin staan de documenten die ik eerder al op mijn server plaatste en ook een CSV-bestand met daarin de postcode-gemeentenaam probleemgevallen. Groeten, Thomas Sander Deryckere schreef op 2-11-2014 9:41: Net mijn laatste wijzigingen gepushed. Zal in de volgende uren geen push meer uitvoeren. Zou je ook de wijzigingen aan loadStreets.js in een aparte comit kunnen steken? Dan is het eenvoudiger om de diff te bekijken. Groeten, Sander ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Het zal wss zijn door de emergency rollback van overpass. Zie subject: [OSM-talk-be] Fwd: [OSM-talk] overpass-api.de: Emergency rollback Glenn On 03-11-14 01:32, Thomas wrote: De overpass-query wordt nu naar de Russische overpass-api gestuurd. Daarmee functioneert de import-pagina nu eerst weer. Uit de foutmeldingen in de javascript leid ik af dat het JSON-antwoord van die Russische api anders is dan die van de Duitse api. Ik heb een check toegevoegd die daarmee moet helpen. Uit de nu resulterende matches leid ik dan weer af dat toch niet alle huisnummers in OSM gedetecteerd worden. Blijkbaar zijn beide api's niet compatibel met elkaar. Op zich werkt het nu dus, zij het met beperkingen. Als over enkele uren de Duitse api het weer blijkt te doen, zal ik die weer koppelen. Als compatibiliteit zo'n lastige zaak is, dan moeten we misschien maar genoegen nemen met een afhankelijkheid van de Duitse api. Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
2014-11-01 1:43 GMT+01:00 Thomas o...@aptum.nl: 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. vergeet niet dat het hier om een geografische databank gaat. Relaties tussen objecten worden ook (in de eerste plaats zelfs) afgeleid uit hun onderlinge positie. Er is geen reden om deze expliciet te maken in een ander object (relatie), zoals bij een relationele databank. Ik dacht tot voor een jaar ook in termen van relaties, maar doordat op de verschillende fora en mailing lists zo dikwijls over dat geografische aspect gehamerd wordt, heb ik mijn mening herzien Het toevoegen van postcode en gemeente tags op een adres vind ik dan weer lastig; waar houdt het op? Je het die enkel nodig voor de paar uitzonderingsgevallen zoals bv die langestraat 14 15 die Jo aanhaalt, omdat dat enclaves zijn binnen een andere postcode grens. De Engelsen doen het bijna uitsluitend met alles op de node omdat hun postcodes geen zones zijn. Ik heb vorig jaar al eens een berekening gemaakt hoeveel ruimte een associatedStreet relatie inneemt versus een expliciete straatnaam tag. Je moest al een lange naam hebben wou de relatie minder getransfereerde bytes inhouden voor JOSM. Geocoders en navigatie programma's herstructuren de data toch nog volledig, dus je weet niet wat daarvoor de interessantse structuur is. Ze kappen bijvoorbeeld toch alle straten verder in stukken op de kruispunten. Dus plaats besparen door een straat niet in stukken te kappen maakt voor hen ook niet uit. Dus voor mij: - alle gemeente grenzen en postcodes in boundary relaties (en ja daar moeten we dan maar werk van maken) - enkel straat en nummer op node - bij uitzonderingsgevallen city postcode op node eenvoudiger kan het niet :-) mvg m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 1 november 2014 01:43 schreef Thomas o...@aptum.nl: 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...). 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. 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. 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). Als je nu dus de adressen van 8820 bekijkt ( http://aptum.github.io/import.html?pcode=8820loadOsm=truecollapsedSections=comparison,export,data#data), dan zie je dat er 2 adressen nog altijd in Oostnieuwkerke liggen (2 dorpen ten zuiden van Torhout). 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. 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
Re: [OSM-talk-be] import AGIV CRAB-data
Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be: Dat is goed bezig een vette tool te worden Ik zie veel fouten in de buurt, maar allemaal op nummers die ik zelf heb gemapt, en waarvan ik zeker ben (3 liggen binnen de 100meter). Het lijkt wel alsof crab vol fouten zit. In veel straten (uitgezonderd nieuwe wijken met tamelijk logische nummering) zit wel een fout. Toch zeker in de gemeenten die CRAB nog niet gevalideerd hebben. Dus ja, er zitten wel veel fouten in CRAB, maar meestal is het duidelijk dat iets fout is (door overlappende adressen, niet-logische volgordes, ...). @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? Glenn On 01-11-14 09:56, Sander Deryckere wrote: Op 1 november 2014 01:43 schreef Thomas o...@aptum.nl mailto:o...@aptum.nl: 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...). 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. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Vooraleer iemand in het komende uur of zo een pull of push wil gaan uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het enige punt waarop ze niet backwards-compatible zijn is het feit dat het huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel gelezen wordt in het script gewoon het eerste element uit de array genomen wordt. Die nieuwe variant van de javascript zit als het goed is mee in die push. Gelieve dus nog even een uurtje te wachten met andere acties, anders komen er mogelijk een hele hoop conflicten. Van zodra de push klaar is, stuur ik nog een mailtje met wat meer informatie over die postcode-gemeente problematiek en wat inhoudelijke informatie over de extra gegevens in de JSON. Het kan even duren; de diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even... Groeten, Thomas Sander Deryckere schreef op 1-11-2014 11:25: Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De problemen die ik zag zijn zo te zien allemaal ondertussen opgelost. De wiki handleiding is handig ook. Tijdens het gebruiken heb ik eigenlijk vooral problemen bij nr notaties van dit type: vb1: nr is 100 , bus 4 varianten die je ziet: - 100b4 - 100/4 vb2: nr is 26 / A - 26A - 26/a - 26a vb3 (moeilijker) - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes), vind ik maar rare nummering. Ik ben al even op zoek in de wiki over wat de consensus nu is over dit soort adressen. Die vind je ook niet terug in CRAB. Maar zo'n nodes zie ik de meeste 'missing in crab' terugkomen. Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen. Glenn On 01-11-14 11:36, Thomas wrote: Vooraleer iemand in het komende uur of zo een pull of push wil gaan uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het enige punt waarop ze niet backwards-compatible zijn is het feit dat het huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel gelezen wordt in het script gewoon het eerste element uit de array genomen wordt. Die nieuwe variant van de javascript zit als het goed is mee in die push. Gelieve dus nog even een uurtje te wachten met andere acties, anders komen er mogelijk een hele hoop conflicten. Van zodra de push klaar is, stuur ik nog een mailtje met wat meer informatie over die postcode-gemeente problematiek en wat inhoudelijke informatie over de extra gegevens in de JSON. Het kan even duren; de diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even... Groeten, Thomas Sander Deryckere schreef op 1-11-2014 11:25: Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Der zit een probleem in de js: sourceHnr = uniformise(sourceAddr.housenumber); sourceHnrLabel = uniformise(sourceAddr.hnrlbls[0]); compHnr = uniformise(compAddr.housenumber); compHnrLabel = uniformise(compAddr.hnrlbls[0]); compAddr is not defined, dus ook geen array. De map laad niet meer. Glenn On 01-11-14 13:12, Thomas wrote: De nieuwe reeks JSON-bestanden staat inmiddels online. Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de huidige werking het feit dat huisnummerlabels nu in een array meegegeven worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het matchen met de gegevens uit OSM. Verder wordt er per adres nu ook, indien aanwezig, een lijst met busnummers en appartementnummers op dat huisnummer meegegeven (allen gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten). Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer zoveel busnummers als appartementnummers. Wanneer voor welke gekozen wordt, is mij niet duidelijk. De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs) die in de laatste varianten van de javascript niet meer ingeladen werd heb ik uit de JSON weggehaald. Ik heb een element “municipality” toegevoegd die de gemeentenaam weergeeft. De postcode was eerder al ontsloten via het element “postc”. Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM, hoewel dat natuurlijk los staat van deze import. Tot slot heb ik een lijst “otherPCs” toegevoegd aan de postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in het huidige systeem niet nodig is, kan het interessante informatie zijn om bepaalde vreemde zaken te analyseren. Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik ook de data-specificatie van de adressenlijst zelf opgenomen. Het bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga ik netjes integreren met de rest van de documentatie en vervolgens als verzamelde documentatie op github plaatsen. Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn en dat de gemeentenaam daarbij noodzakelijk is om het adres te identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een hele verzameling subadressen (met elk een eigen busnummer / appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik heb de volledige dataset expliciet doorzocht naar een situatie waarbij er voor een combinatie van postcode-straatnaam-huisnummer meerdere gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen. Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen waar een postcode zich over meerdere gemeenten uitstrekt. We weten al dat deze situatie zich slechts voor 253 adressen binnen de volledige dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt wel eens de systematisch fout kan zijn: iets met gemeentelijke herindelingen. Dat is de enige logica die in de collectie fouten lijkt te zitten. Om dat verder uit te zoeken heb ik volgend document opgesteld: http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de betreffende 253 adressen per straat gegroepeerd en het aantal adressen per straat aangegeven. De postcode en gemeente zijn de gegevens zoals die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten voor de opgegeven postcode. De vraag is dus hoe beide gemeenten gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat de opgegeven postcodes nog “oude” postcodes zijn van voor de gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt, maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst. In de adressenlijst zitten geen gegevens over de status van het adres (zie ook de data-specificatie hierboven). Mogelijk is dat wel een achterliggende reden: dat de adressen in de praktijk geschrapt zijn en daarmee niet bijgewerkt worden, maar dat ze niet formeel een statuswijziging gekregen hebben in de database. Dat zal het Agiv echter moeten uitzoeken.
Re: [OSM-talk-be] import AGIV CRAB-data
Hoi, Misschien een kleine bijdrage ivm adressering (busnummers, cijfers in straatnamen e.d.). De post zegt op http://www.bpost.be/adressering/ hoe het allemaal zou moeten. Kan een reden zijn om in osm dezelfde regels te volgen. Groetje, Stijn From: Glenn Plas gl...@byte-consult.be To: OpenStreetMap Belgium talk-be@openstreetmap.org Sent: Saturday, November 1, 2014 12:31 PM Subject: Re: [OSM-talk-be] import AGIV CRAB-data Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De problemen die ik zag zijn zo te zien allemaal ondertussen opgelost. De wiki handleiding is handig ook. Tijdens het gebruiken heb ik eigenlijk vooral problemen bij nr notaties van dit type: vb1: nr is 100 , bus 4 varianten die je ziet: - 100b4 - 100/4 vb2: nr is 26 / A - 26A - 26/a - 26a vb3 (moeilijker) - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes), vind ik maar rare nummering. Ik ben al even op zoek in de wiki over wat de consensus nu is over dit soort adressen. Die vind je ook niet terug in CRAB. Maar zo'n nodes zie ik de meeste 'missing in crab' terugkomen. Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen. Glenn On 01-11-14 11:36, Thomas wrote: Vooraleer iemand in het komende uur of zo een pull of push wil gaan uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het enige punt waarop ze niet backwards-compatible zijn is het feit dat het huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel gelezen wordt in het script gewoon het eerste element uit de array genomen wordt. Die nieuwe variant van de javascript zit als het goed is mee in die push. Gelieve dus nog even een uurtje te wachten met andere acties, anders komen er mogelijk een hele hoop conflicten. Van zodra de push klaar is, stuur ik nog een mailtje met wat meer informatie over die postcode-gemeente problematiek en wat inhoudelijke informatie over de extra gegevens in de JSON. Het kan even duren; de diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even... Groeten, Thomas Sander Deryckere schreef op 1-11-2014 11:25: Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Hooi, Leopoldsburg heeft 2 zonenummers, 3970 en 3971 (vroeger Heppen). De Vaartstraat loopt door de 2 zones. Nummers 120 en 134 liggen in 3971, maar 122,126, 128, 130 en 132 die er tussen liggen vindt men in 3970, wat fout is, ook volgens Bpost. Fout dus in CRAB. Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 1-nov.-2014 17:30 schreef Stijn Rombauts stijnromba...@yahoo.com: Hoi, Misschien een kleine bijdrage ivm adressering (busnummers, cijfers in straatnamen e.d.). De post zegt op http://www.bpost.be/adressering/ hoe het allemaal zou moeten. Kan een reden zijn om in osm dezelfde regels te volgen. Groetje, Stijn Dit is hoe we het al doen in OSM. Enkel de schrijfwijze van numeriek uitgebreide huisnummers (zoals 16/2) is hier expliciet vermeld, terwijl het in crab 16_2 is. Dat es ook iets wat ik al eerder vermeld had. Dus niets nieuws. Groeten, Sander. From: Glenn Plas gl...@byte-consult.be To: OpenStreetMap Belgium talk-be@openstreetmap.org Sent: Saturday, November 1, 2014 12:31 PM Subject: Re: [OSM-talk-be] import AGIV CRAB-data Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De problemen die ik zag zijn zo te zien allemaal ondertussen opgelost. De wiki handleiding is handig ook. Tijdens het gebruiken heb ik eigenlijk vooral problemen bij nr notaties van dit type: vb1: nr is 100 , bus 4 varianten die je ziet: - 100b4 - 100/4 vb2: nr is 26 / A - 26A - 26/a - 26a vb3 (moeilijker) - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes), vind ik maar rare nummering. Ik ben al even op zoek in de wiki over wat de consensus nu is over dit soort adressen. Die vind je ook niet terug in CRAB. Maar zo'n nodes zie ik de meeste 'missing in crab' terugkomen. Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen. Glenn On 01-11-14 11:36, Thomas wrote: Vooraleer iemand in het komende uur of zo een pull of push wil gaan uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het enige punt waarop ze niet backwards-compatible zijn is het feit dat het huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel gelezen wordt in het script gewoon het eerste element uit de array genomen wordt. Die nieuwe variant van de javascript zit als het goed is mee in die push. Gelieve dus nog even een uurtje te wachten met andere acties, anders komen er mogelijk een hele hoop conflicten. Van zodra de push klaar is, stuur ik nog een mailtje met wat meer informatie over die postcode-gemeente problematiek en wat inhoudelijke informatie over de extra gegevens in de JSON. Het kan even duren; de diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even... Groeten, Thomas Sander Deryckere schreef op 1-11-2014 11:25: Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl: De nieuwe reeks JSON-bestanden staat inmiddels online. Bedankt, zal eens kijken als alles nog werkt, en wat er toegevoegd is ;) Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de huidige werking het feit dat huisnummerlabels nu in een array meegegeven worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het matchen met de gegevens uit OSM. Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit gebeurt. Ik weet niet goed hoe ik foute data kan vergelijken, buiten melden dat er ergens een fout zit. Zal het verder onderzoeken. Verder wordt er per adres nu ook, indien aanwezig, een lijst met busnummers en appartementnummers op dat huisnummer meegegeven (allen gesorteerd en gefilterd zodat de lijsten geen dubbele waarden bevatten). Hoe beide lijsten zich tot elkaar verhouden kan nu in de praktijk bekeken worden. Mogelijk is er soms overlap. Daarnaast zijn er 4 keer zoveel busnummers als appartementnummers. Wanneer voor welke gekozen wordt, is mij niet duidelijk. De “message” (die in tekstvorm informatie gaf over busnrs en apptnrs) die in de laatste varianten van de javascript niet meer ingeladen werd heb ik uit de JSON weggehaald. Ik heb een element “municipality” toegevoegd die de gemeentenaam weergeeft. De postcode was eerder al ontsloten via het element “postc”. Er kan nu gekeken worden of en onder welke tags deze gegevens in JOSM ingeladen moeten worden. Daarnaast kunnen de gegevens gebruikt worden voor een verificatie van bestaande gemeente- en postcodegrenzen in OSM, hoewel dat natuurlijk los staat van deze import. Tot slot heb ik een lijst “otherPCs” toegevoegd aan de postcode-JSON-bestanden, die (indien aanwezig) een lijst geeft met de andere postcodes waar de betreffende straat in doorloopt. Hoewel dat in het huidige systeem niet nodig is, kan het interessante informatie zijn om bepaalde vreemde zaken te analyseren. Ook heb ik een overzicht gemaakt van de gebruikte JSON-elementen zodat voor iedereen duidelijk is welke informatie beschikbaar wordt gesteld via de JSON-bestanden en op welke manier dat gebeurt. Daarnaast heb ik ook de data-specificatie van de adressenlijst zelf opgenomen. Het bestand staat nu op http://downloader.aptum.nl/data_format.pdf maar ga ik netjes integreren met de rest van de documentatie en vervolgens als verzamelde documentatie op github plaatsen. Dan over die vreemde postcode-gemeente overlap. Ben gaf eerder aan dat er situaties zijn waarin postcode-straatnaam-huisnummer niet uniek zijn en dat de gemeentenaam daarbij noodzakelijk is om het adres te identificeren. Uiteraard heb je per postcode-straatnaam-huisnummer een hele verzameling subadressen (met elk een eigen busnummer / appartementnummer) maar dat was uiteraard niet wat er bedoeld werd. Ik heb de volledige dataset expliciet doorzocht naar een situatie waarbij er voor een combinatie van postcode-straatnaam-huisnummer meerdere gemeenten geregistreerd waren, maar die heb ik niet kunnen aantreffen. Als deze situatie zich zou voordoen, dan kan dit enkel voor de gevallen waar een postcode zich over meerdere gemeenten uitstrekt. We weten al dat deze situatie zich slechts voor 253 adressen binnen de volledige dataset (2.639.893 echte adressen) voordoet. Van die 253 adressen die een gemeentenaam hebben die je niet bij die postcode verwacht, lijkt het meestal om vergissingen te gaan. Ik heb het idee dat wat Sander aanhaalt wel eens de systematisch fout kan zijn: iets met gemeentelijke herindelingen. Dat is de enige logica die in de collectie fouten lijkt te zitten. Om dat verder uit te zoeken heb ik volgend document opgesteld: http://downloader.aptum.nl/multiple_NIS_per_PC.pdf . Daarin heb ik de betreffende 253 adressen per straat gegroepeerd en het aantal adressen per straat aangegeven. De postcode en gemeente zijn de gegevens zoals die voor dat adres in de CRAB-adressenlijst zijn opgegeven. De Gemeente_verwacht is de gemeente zoals mijn script die zou verwachten voor de opgegeven postcode. De vraag is dus hoe beide gemeenten gerelateerd zijn. Zoals Sander al schreef is de kans zeer aanwezig dat de opgegeven postcodes nog “oude” postcodes zijn van voor de gemeentelijke herindeling, en dat de opgegeven gemeente dus wel klopt, maar dat de postcode verouderd is. Ik ga dat proberen systematisch na te zoeken. In elk geval betreft het hier fouten in de CRAB-adressenlijst. In de adressenlijst zitten geen gegevens over de status van het adres (zie ook de data-specificatie hierboven). Mogelijk is dat wel een achterliggende reden: dat de adressen in de praktijk geschrapt zijn en daarmee niet bijgewerkt worden, maar dat ze niet formeel een statuswijziging gekregen hebben in de database. Dat zal het Agiv echter moeten uitzoeken. Verdere analyse moet uitwijzen of er ook “correcte” gegevens
Re: [OSM-talk-be] import AGIV CRAB-data
Op 1 november 2014 13:15 schreef Gilbert Hersschens gherssch...@gmail.com: Ik heb even een poging gedaan. Ziet er wel handig uit, maar bij appartementen geeft hij een hoop missing nummers op omdat hij geen rekening houdt met get gebruik van een bereik van nummers. Ik ben eerlijk gezegd niet van zin om ieder individueel huisnummer van elk apt dat in een appartementsblok zit in te tikken. Ik weet wel dat er discussie is hierover (zie de desbetreffende wiki https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers) maar zowel de AGIV/Geopunt kaart alsook in sommige gevallen de plaatjes op de appartementen zelf tonen alle mogelijke varianten van nummering. Ter illustratie een paar foto's op https://drive.google.com/folderview?id=0B_mcNCW4oRVOSE13OGZEM040UzQusp=sharing . Overigens zitten er ook nog andere fouten in, maar dat ligt misschien aan de data in CRAB? Zo geeft hij bv. voor Elsum 191-191C in Geel (2440) op dat hier de nummers 191A, B, C en D zouden moeten staan terwijl nummer 191 (zonder suffix) er ook bij hoort. Zie fofo op de link hierboven. Gilbert De tool houdt wel rekening met het bereik. Het zal bijvoorbeeld nummers 5 en 7 als missing opgeven, maar als die nummers in de werkelijkheid overlappen (ze zijn beiden huisnummer van hetzelfde gebouw), en je voegt een gebouw toe met nummer 5-7, dan zouden er twee missing nummers minder moeten zijn. Daarnaast moet je ook goed het verschil tussen bus/appartementnummers en bisnummers weten. Bisnummers zijn deel van het huisnummer. bus- en apartementnummers zijn verschillende brievenbussen met dezelfde voordeur. Bij de bisnummers kan het gebeuren dat er verschillende gebouwen bedoeld zijn, en dat ze dus apart gemapt moeten worden. Maar het kan ook gebeuren dat hetzelfde gebouw (Eventueel met een andere ingang) bedoeld is, en in dat geval zal bijvoorbeeld het huisnummer 7-7A aanvaard worden. Bus- en appartementsnummers zijn echter nooit deel van het huisnummer, en zullen altijd op hetzelfde gebouw getagd zijn. Bijvoorbeeld een gebouw met de tags addr:street = Dorpsstraat addr:housenumber = 5 addr:flats = 1,2,3,4,5,6 heeft 6 appartementnummers op dat ene adres. De meeste foto's die jij toont zijn waarschijnlijk bus- of appartementnummers. Die zullen normaal gezien zelfs nooit apart verschijnen in CRAB. Zou je met de bovenstaande info je probleemgevallen nog eens kunnen controleren? Groeten, Sander 2014-11-01 12:31 GMT+01:00 Glenn Plas gl...@byte-consult.be: Heb nog niks concreet eigenlijk, maar wel paar ideetjes alvast. De problemen die ik zag zijn zo te zien allemaal ondertussen opgelost. De wiki handleiding is handig ook. Tijdens het gebruiken heb ik eigenlijk vooral problemen bij nr notaties van dit type: vb1: nr is 100 , bus 4 varianten die je ziet: - 100b4 - 100/4 vb2: nr is 26 / A - 26A - 26/a - 26a vb3 (moeilijker) - 46 / 0001 en 46 / 0101 (2-woonst... op het gebouw zo op de plaatjes), vind ik maar rare nummering. Ik ben al even op zoek in de wiki over wat de consensus nu is over dit soort adressen. Die vind je ook niet terug in CRAB. Maar zo'n nodes zie ik de meeste 'missing in crab' terugkomen. Ik hou me nog wel wat in tot ik iets echt nuttig kan toevoegen. Glenn On 01-11-14 11:36, Thomas wrote: Vooraleer iemand in het komende uur of zo een pull of push wil gaan uitvoeren: ik sta op het punt de nieuwe JSON bestanden te pushen. Het enige punt waarop ze niet backwards-compatible zijn is het feit dat het huisnummerlabel nu in een lijst zit. Ik heb de loadStreets.js al aangepast naar een vorm waarin voor de 5x dat een huisnummerlabel gelezen wordt in het script gewoon het eerste element uit de array genomen wordt. Die nieuwe variant van de javascript zit als het goed is mee in die push. Gelieve dus nog even een uurtje te wachten met andere acties, anders komen er mogelijk een hele hoop conflicten. Van zodra de push klaar is, stuur ik nog een mailtje met wat meer informatie over die postcode-gemeente problematiek en wat inhoudelijke informatie over de extra gegevens in de JSON. Het kan even duren; de diff maken voor die hele berg JSON-bestanden duurt vaak wel echt even... Groeten, Thomas Sander Deryckere schreef op 1-11-2014 11:25: Op 1 november 2014 10:30 schreef Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be: @Sander Accepteer je de occasionele commits of pull requests? Zeker, waarover gaat het? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org
Re: [OSM-talk-be] import AGIV CRAB-data
2014-10-31 16:22 GMT+01:00 Sander Deryckere sander...@gmail.com: 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). Net de eerste field-test achter de rug met die bestanden. Alle 3 de bestanden voor 2840 gedownload en op mijn Garmin Dakota 10 gezet. Eerste probleem: de Dakota heeft niet genoeg geheugen. Ik kon geen waypoints meer bijmaken. Als iemand een programma kent (OSX) dat waypoints kan beperken binnen een bounding box, laat het maar weten. Ik zal eens met Basecamp proberen. 2de probleem, de namen van de waypoints zijn te lang. Ze worden afgekapt, zodat je de huisnummers niet meer ziet. Sander, zou je de fout kunnen korter maken en de nummer naar voor kunnen brengen ? (ipv van vb. missing_overlapping_Kardinaal_Cardijnstraat xx misov_xx_Kardidaal_Cardijnstraat. Aan de korte naam van de fout wennen we wel en de straatnaam is zelfs onvolledige nog wel te herkennen. Zeker omdat het punt toch juist staat. met vriendelijke groeten m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Het gebeurt in totaal 702 keer over alle adressen (inclusief subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27 oktober mailde ik dit daarover: Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf In dat pdf-document krijg je een overzicht van huisnummer-labels die niet systematisch gelijk zijn voor alle subadressen voor dat huisnummer. Meestal lijkt het om vrij logische fouten te gaan. Hoe het kan dat dit niet consistent is in de CRAB-adressenlijst is mij niet duidelijk. Ik heb het gevoel dat het om een versie-probleempje gaat, dat niet alle huisnummers systematisch worden bijgewerkt wanneer een subadres wordt toegevoegd of wordt verwijderd. Omdat ik geen verder onderscheid kon maken tussen goede en foute huisnummers leek het mij het beste om ze gewoon allemaal mee te geven in de JSON. Groeten, Thomas Sander Deryckere schreef op 1-11-2014 20:15: Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl mailto:o...@aptum.nl: Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de huidige werking het feit dat huisnummerlabels nu in een array meegegeven worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het matchen met de gegevens uit OSM. Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit gebeurt. Ik weet niet goed hoe ik foute data kan vergelijken, buiten melden dat er ergens een fout zit. Zal het verder onderzoeken. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Thomas,
In je spec staat dat busnummers en appartementnummers arrays zijn, maar in
werkelijkheid lijken het comma-separated strings. Zou je het kunnen
wijzigen naar arrays? Arrays lijken veiliger voor het geval een busnummer
plots ook een komma bevat.
Verder zijn er idd eigenaardige adressen. Dit zijn er twee in mijn dorp:
{
apptnrs: 0/1,0/2,1/1,1/2,1/3,2/1,2/2,2/3,3/1,3/2,
busnrs: 1,11,3,
hnrlbls: [
22-26
],
housenumber: 22,
lat: 50.94126031777649,
lon: 3.061661179477891,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
Let op, nr 22 heeft hier veel bus- en appartementsnummers, nummer 26 blijkt
er geen te hebben.
{
apptnrs: 0/1,1/3,2/1,2/2,2/3,3/3,
busnrs: 1,2,
hnrlbls: [
7
],
housenumber: 7,
lat: 50.94025949900766,
lon: 3.060482929425432,
municipality: Staden,
pcode: 8840,
source: afgeleidVanGebouw,
street: Roeselarestraat
},
In beide gevallen lijkt er totaal geen verband tussen de busnummers en
appartementsnummers te bestaan. Ik zal morgen of overmorgen eens bekijken
wat er daar nu net zichtbaar is.
Momenteel zal ik dus nog geen toevoegen aan de uitvoer. Iedereen die meer
info kan geven is zeker welkom.
Groeten,
Sander
Op 1 november 2014 20:43 schreef Thomas o...@aptum.nl:
Het gebeurt in totaal 702 keer over alle adressen (inclusief
subadressen) heen. Daarbij zijn 211 huisnummers betrokken. Op 27 oktober
mailde ik dit daarover:
Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die
worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo
hoort het. Toch heb ik met een check in mijn script 702 afwijkende
huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat
natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal.
Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich
voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan.
Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst
op mijn server geplaatst:
http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf
In dat pdf-document krijg je een overzicht van huisnummer-labels die niet
systematisch gelijk zijn voor alle subadressen voor dat huisnummer. Meestal
lijkt het om vrij logische fouten te gaan. Hoe het kan dat dit niet
consistent is in de CRAB-adressenlijst is mij niet duidelijk. Ik heb het
gevoel dat het om een versie-probleempje gaat, dat niet alle huisnummers
systematisch worden bijgewerkt wanneer een subadres wordt toegevoegd of
wordt verwijderd. Omdat ik geen verder onderscheid kon maken tussen goede
en foute huisnummers leek het mij het beste om ze gewoon allemaal mee
te geven in de JSON.
Groeten,
Thomas
Sander Deryckere schreef op 1-11-2014 20:15:
Op 1 november 2014 13:12 schreef Thomas o...@aptum.nl:
Zoals eerder gezegd is de voornaamste wijziging die invloed heeft op de
huidige werking het feit dat huisnummerlabels nu in een array meegegeven
worden, zodat bij meerdere huisnummer-labels per huisnummer, deze allemaal
doorgegeven kunnen worden. Dat kan Sander misschien helpen bij het matchen
met de gegevens uit OSM.
Gebeurt dit vaak? Het lijkt me sowieso een fout in CRAB als dit
gebeurt. Ik weet niet goed hoe ik foute data kan vergelijken, buiten melden
dat er ergens een fout zit. Zal het verder onderzoeken.
___
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
Re: [OSM-talk-be] import AGIV CRAB-data
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 https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
die GPX bestanden gaan zeker van pas komen. hartelijk dank ! m 2014-10-31 16:22 GMT+01:00 Sander Deryckere sander...@gmail.com: 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 https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Sander, Thomas, op http://aptum.github.io/import.html moet ik nadat ik op 'update' heb gedrukt, nu een back doen om de data te zien. platform Chrome op OSX. veel debug plezier (niet zonder leedvermaak, na een dag van bug hunting op het werk :-) ) 2014-10-31 17:54 GMT+01:00 Marc Gemis marc.ge...@gmail.com: die GPX bestanden gaan zeker van pas komen. hartelijk dank ! m 2014-10-31 16:22 GMT+01:00 Sander Deryckere sander...@gmail.com: 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 https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
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 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 https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
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: 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 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 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
Re: [OSM-talk-be] import AGIV CRAB-data
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
Re: [OSM-talk-be] import AGIV CRAB-data
Reeds enkele weken volg ik de discutie over de adressen. Eigenlijk snap ik er weinig van. Ik wil me niet bij de echte mappers rekenen maar echt beginnend ben ik toch ook niet. Maanden geleden ben ik begonnen met in de streek rond Tienen huisnummers in te brengen. Maar toen ik op het forum meende te begrijpen dat het automatisch zou kunnen ben ik natuurlijk gestopt. En nu, weet ik het niet meer. Moet ik terug beginnen of moet ik nog wachten. Er zijn misschien efficiëntere manieren om adressen te mappen dan de manier waarop ik het doe maar anderzijds… als ik er 1000 doe zijn er 1000 gedaan. Of worden die bij een eventuele automatisering toch overschreven? Mijn manier is gewoon met AGIV luchtfoto’s de huizen van een straat tekenen en dan met RGB-AGIV er de nummers proberen op te zetten. Bij problemen ga ik dan gewoon eens kijken of ik ter plaatse de zaak kan oplossen. Een kleine anekdote: In het Medekersveld in KUmtich (Tienen) staan vooraan 3 huizen aan de linkerkant: 1, 3 en 5. Enkele honderden meters verder dat er nog één huis. Volgens AGIV is dat nr 7. Nochtans had ik in OSM nr 100 ingebracht. Op het huis of op de brievenbus staat geen nummer, maar in de (geopende) brievenbus vond ik een brief met nr 100. Wie heeft nu gelijk? O ja, als de huizen getekend zijn gebruik ik het ‘adres tool’ en daar blijven de gegevens voor straat, gemeente, enz. gewoon staan en moet je alleen het nummer wijzigen. Bij het gereedschap ‘Rijtjeshuis maken’ komen de straten enz; automatisch in een associatedStreet relatie. Ik bewonder diegenen die, dank zij een of ander script, bergen werk kunnen herleiden tot een niemendalletje maar ik vrees dat er niet zoveel mappers zijn die nog kunnen volgen. Het moet eenvoudig blijven zodat ‘niet programmeurs’ ook nog mee kunnen want dat zijn de mensen die meestal het meest tijd hebben om ‘veldwerk’ te doen. GuyVV Van: Marc Gemis [mailto:marc.ge...@gmail.com] Verzonden: donderdag 30 oktober 2014 11:11 Aan: Jo Simoens; OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] import AGIV CRAB-data Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet relaties wil werken. Als ik in de landen om ons heen kijk, breken ze associatedStreet allemaal af. (in de figuurlijke zin) Dus waar ga je support krijgen voor data in die relatie ? Op het minieme gebruik van Nominatim na, dat dan nog niet hetzelfde doet als jij zou willen ? Ben, als je jouw approach volgt (alles op node), zou ik dat toch ook eerst testen op osm.org. Leg anders maar eens uit aan een beginnende mapper dat hoewel hij een postcode op een node plaatst er toch een andere uitrolt. Ik weet dat je niet met bepaalde software in je achterhoofd mag mappen, maar als er nu iemand naar osm.org gaat en het verkeerde adres rolt eruit, dan stopt het voor velen (dat is mijn mening, niet wetenschappelijk getest). Het is weeral een tijdje geleden dat ik op dat gebied nog testen gedaan heb, dus nominatim is misschien gewijzigd ondertussen, maar data van een node werd genegeerd. Het is voor mij gemakkelijker uit te leggen dat een boundary is gebroken dan om iemand wijs te maken dat de data wel juist is, maar dat de gekendste website (osm.org) er geen gebruik van maakt. just my .5 cent m 2014-10-30 9:37 GMT+01:00 Jo winfi...@gmail.com: Als je de data aangeleverd krijgt, inclusief de associatedStreet-relatie, dan is het niet zo'n grote uitdaging om uit te leggen, waar dat voor staat. Zelfs kinderen, vanaf een jaar of 10 kunnen dat begrijpen. We moeten de mensen die bijdragen aan OSM nu weer niet al te veel gaan onderschatten. Laten we niet vergeten dat het om miljoenen adressen gaat voor Vlaanderen alleen. Als al die adressen er eenmaal inzitten, moet je al die rompslomp elke keer weer over de draad trekken als je dat inlaadt en verwerkt. Ik heb nog steeds een datalimiet op 3G. We hoeven niet superefficiënt te zijn, maar om nu in het andere uiterste te vervallen, gewoon omdat we willen dat een kind van 7 het ook zou kunnen snappen... Ik gebruik die aS-relaties trouwens ook om snel een (grafisch) overzicht te krijgen van een straat. Waar zijn er nog adressen als node gemapt, e.d. De validatietools geven ook wat meldingen, maar die staan nog niet helemaal op punt, voor onze situaties waar straten soms in meerdere aS-relaties thuishoren. Jo Op 30 oktober 2014 09:10 schreef Ben Abelshausen ben.abelshau...@gmail.com: Hey, 2014-10-30 8:41 GMT+01:00 Jo winfi...@gmail.com: Wat mij betreft is een adres niet compleet, zonder postcode en gemeente. Ik ben het hiermee eens. Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, gemeente. Associated street klinkt logisch en best
Re: [OSM-talk-be] import AGIV CRAB-data
Hallo Guy, De discussie is op dit moment nogal technisch. Dit is met de bedoeling om de data 'klaar te stomen', zodat iedereen er vlot gebruik van kan maken. Dat je die discussie niet altijd kan volgen, maak je daar geen zorgen over. We zullen nog wat meetings en hangouts moeten organiseren om te zorgen dat iedereen weet hoe deze dat in OSM te integreren. Want helemaal automatisch zal dat zeker niet gebeuren. Ik ben er bij wijze van test een aantal aan het invoeren en ik kan je verzekeren, dat het nog heel wat werk kost, als je het goed wilt doen. Het enige verschil is dat de huisnummers op nodes worden aangeleverd. Dan moeten ze nog op de gebouwen worden overgezet. Als deze gebouwen er nog niet zijn, kan je met de building tools er met 3 klikken een rechthoek overheen tekenen en wordt de info van de node naar het gebouw overgedragen. Als dat gebouw parallel staat met het gebouw ernaast, kan het ook met 2 klikken. Als het gebouw al in OSM zit, dan zijn er een aantal mogelijkheden. Het komt er echter bijna altijd wel op neer dat je de geometrie van het gebouw ook nog wat moet aanpassen. Opnieuw tekenen zou soms zelfs sneller gaan. (Maar we willen wel de historiek intact houden). Gebouwen zijn natuurlijk niet altijd rechthoekig, maar de extrude tool (x) kan hierbij enorm behulpzaam zijn. (als je in extrude mode zit, kan je met dubbelklik ook nodes op de contour van het gebouw toevoegen). Als je een gebouw wilt tekenen dat parallel is, houd je het vorige geselecteerd. Als je echter een gebouw wilt tekenen dat aanligt bij het vorige, dan kan je beginnen op 1 van de nodes ervan, dan een 2e aanklikken en dan beginnen 'uitrekken'. Dan zijn de nodes vanzelf deel van beide gebouwen. Gebouwen met curves kunnen tegenwoordig ook mooi afgewerkt worden met 'o'. Voor bestaande gebouwen kan je de conflation tool gebruiken. Je kan echter ook in het menu selection,* 'Select all inside'* kiezen. Als dat 1 node en 1 gebouw oplevert, kan je daarna *'Replace Geometry'* gebruiken om beide samen te voegen. Je krijgt dan nog een dialoogvenster als er conflicten zijn. Ik heb die respectievelijk op 't' en 'v' gemapt. (Je kan de sneltoetsen voor je tools aanpassen aan je eigen voorkeuren) Jo Op 30 oktober 2014 11:45 schreef Guy Vanvuchelen guy.vanvuche...@gmail.com : Reeds enkele weken volg ik de discutie over de adressen. Eigenlijk snap ik er weinig van. Ik wil me niet bij de echte mappers rekenen maar echt beginnend ben ik toch ook niet. Maanden geleden ben ik begonnen met in de streek rond Tienen huisnummers in te brengen. Maar toen ik op het forum meende te begrijpen dat het automatisch zou kunnen ben ik natuurlijk gestopt. En nu, weet ik het niet meer. Moet ik terug beginnen of moet ik nog wachten. Er zijn misschien efficiëntere manieren om adressen te mappen dan de manier waarop ik het doe maar anderzijds… als ik er 1000 doe zijn er 1000 gedaan. Of worden die bij een eventuele automatisering toch overschreven? Mijn manier is gewoon met AGIV luchtfoto’s de huizen van een straat tekenen en dan met RGB-AGIV er de nummers proberen op te zetten. Bij problemen ga ik dan gewoon eens kijken of ik ter plaatse de zaak kan oplossen. Een kleine anekdote: In het Medekersveld in KUmtich (Tienen) staan vooraan 3 huizen aan de linkerkant: 1, 3 en 5. Enkele honderden meters verder dat er nog één huis. Volgens AGIV is dat nr 7. Nochtans had ik in OSM nr 100 ingebracht. Op het huis of op de brievenbus staat geen nummer, maar in de (geopende) brievenbus vond ik een brief met nr 100. Wie heeft nu gelijk? O ja, als de huizen getekend zijn gebruik ik het ‘adres tool’ en daar blijven de gegevens voor straat, gemeente, enz. gewoon staan en moet je alleen het nummer wijzigen. Bij het gereedschap ‘Rijtjeshuis maken’ komen de straten enz; automatisch in een associatedStreet relatie. Ik bewonder diegenen die, dank zij een of ander script, bergen werk kunnen herleiden tot een niemendalletje maar ik vrees dat er niet zoveel mappers zijn die nog kunnen volgen. Het moet eenvoudig blijven zodat ‘niet programmeurs’ ook nog mee kunnen want dat zijn de mensen die meestal het meest tijd hebben om ‘veldwerk’ te doen. GuyVV *Van:* Marc Gemis [mailto:marc.ge...@gmail.com] *Verzonden:* donderdag 30 oktober 2014 11:11 *Aan:* Jo Simoens; OpenStreetMap Belgium *Onderwerp:* Re: [OSM-talk-be] import AGIV CRAB-data Jo, jammer genoeg ben je nog zo wat de enige die nog met associatedStreet relaties wil werken. Als ik in de landen om ons heen kijk, breken ze associatedStreet allemaal af. (in de figuurlijke zin) Dus waar ga je support krijgen voor data in die relatie ? Op het minieme gebruik van Nominatim na, dat dan nog niet hetzelfde doet als jij zou willen ? Ben, als je jouw approach volgt (alles op node), zou ik dat toch ook eerst testen op osm.org. Leg anders maar eens uit aan een beginnende mapper dat hoewel hij een postcode op een node plaatst er toch een andere uitrolt. Ik weet dat je
Re: [OSM-talk-be] import AGIV CRAB-data
Ik deel die mening ook over die relaties. En zeker over interpolation van adressen in Belgie springt het van tijd wel heel hard, ik weet een straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv 1,2,3,4,5 8 Dus geen even/oneven verdeling zoals we gewoon zijn. Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is vooral vanuit mijn eigen ervaring met nominatim servers te bouwen. Glenn On 30-10-14 11:57, Sander Deryckere wrote: Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te liggen? Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders. Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die grenzen aanpassen, en niet alles wat er binnen ligt. We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar dat is niet het primaire doel van deze import. Grenzen verbeteren is trouwens een piece of cake vergeleken met het importeren van alle adressen. Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden van de adressen. Iedere mapper is natuurlijk vrij te doen wat hij wil. Groeten, Sander Op 30 oktober 2014 09:10 schreef Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Hey, 2014-10-30 8:41 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: Wat mij betreft is een adres niet compleet, zonder postcode en gemeente. Ik ben het hiermee eens. Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, gemeente. Associated street klinkt logisch en best vertrekkende vanuit kennis van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is dat we nodig hebben is meer mappers. Werken met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt met werken als er een boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar het gebouw in een andere?!). Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd, locaties van adressen zijn niet altijd logisch tov straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer is NIET overal uniek). Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in de tools. Maar op zich is het geen probleem dat die ene straat 2 keer hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo werken als het moet tenzij een max afstand ingegeven is. Maar ik denk niet dat er veel dergelijke straten zijn. De boodschap is: keep it simple! Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website, klikken op gebouw of node en een paar veldjes invullen. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ 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 -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ziehier een prachtvoorbeeld van hoe scheef het kan lopen: https://www.openstreetmap.org/relation/1523419/history https://www.openstreetmap.org/relation/1523417/history https://www.openstreetmap.org/relation/1524225/history Maar wat wil je dan op een grens tussen de provincies... Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden: https://www.openstreetmap.org/node/1495908473/history Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend genummerd en aan de andere kant even/oneven met een andere reeks nummers en ze heet tegelijk Langstraat en Langestraat op die gedeeltes. Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit. Jo Op 30 oktober 2014 12:20 schreef Glenn Plas gl...@byte-consult.be: Ik deel die mening ook over die relaties. En zeker over interpolation van adressen in Belgie springt het van tijd wel heel hard, ik weet een straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv 1,2,3,4,5 8 Dus geen even/oneven verdeling zoals we gewoon zijn. Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is vooral vanuit mijn eigen ervaring met nominatim servers te bouwen. Glenn On 30-10-14 11:57, Sander Deryckere wrote: Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te liggen? Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders. Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die grenzen aanpassen, en niet alles wat er binnen ligt. We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar dat is niet het primaire doel van deze import. Grenzen verbeteren is trouwens een piece of cake vergeleken met het importeren van alle adressen. Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden van de adressen. Iedere mapper is natuurlijk vrij te doen wat hij wil. Groeten, Sander Op 30 oktober 2014 09:10 schreef Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Hey, 2014-10-30 8:41 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: Wat mij betreft is een adres niet compleet, zonder postcode en gemeente. Ik ben het hiermee eens. Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, gemeente. Associated street klinkt logisch en best vertrekkende vanuit kennis van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is dat we nodig hebben is meer mappers. Werken met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt met werken als er een boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar het gebouw in een andere?!). Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd, locaties van adressen zijn niet altijd logisch tov straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer is NIET overal uniek). Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in de tools. Maar op zich is het geen probleem dat die ene straat 2 keer hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo werken als het moet tenzij een max afstand ingegeven is. Maar ik denk niet dat er veel dergelijke straten zijn. De boodschap is: keep it simple! Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven om toe te voegen en te wijzigen. Dat wil zeggen: inloggen op website, klikken op gebouw of node en een paar veldjes invullen. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
2014-10-30 13:13 GMT+01:00 Jo winfi...@gmail.com: Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden: Mooi voorbeeld, 14 en 15 op googlemaps: https://www.google.be/maps/place/Langestraat+15,+3128+Tremelo https://www.google.be/maps/place/Langestraat+14,+3128+Tremelo Haha! Allebei fout en dan op op een andere manier verkeerd ook! ;-) Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Vul nu Langestraat 14, Baal (daar moet ze toch inliggen niet ?) in op osm.org of nominatim.openstreetmap.org Ik geloof niet dat daar het gewenste resultaat uitkomt. Of wel ? (het resultaat is: House 14, Schrieksesteenweg, Baal, Flanders, 3128, Belgium) Leg dat maar eens uit een een beginnende mapper. Maak maar al deze complexe relaties aan dan komt het wel goed zolang er geen support is van Nominatim is het volgens mij gewoon zinloos. mvg m. 2014-10-30 13:13 GMT+01:00 Jo winfi...@gmail.com: Ziehier een prachtvoorbeeld van hoe scheef het kan lopen: https://www.openstreetmap.org/relation/1523419/history https://www.openstreetmap.org/relation/1523417/history https://www.openstreetmap.org/relation/1524225/history Maar wat wil je dan op een grens tussen de provincies... Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden: https://www.openstreetmap.org/node/1495908473/history Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend genummerd en aan de andere kant even/oneven met een andere reeks nummers en ze heet tegelijk Langstraat en Langestraat op die gedeeltes. Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit. Jo Op 30 oktober 2014 12:20 schreef Glenn Plas gl...@byte-consult.be: Ik deel die mening ook over die relaties. En zeker over interpolation van adressen in Belgie springt het van tijd wel heel hard, ik weet een straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv 1,2,3,4,5 8 Dus geen even/oneven verdeling zoals we gewoon zijn. Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is vooral vanuit mijn eigen ervaring met nominatim servers te bouwen. Glenn On 30-10-14 11:57, Sander Deryckere wrote: Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te liggen? Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders. Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die grenzen aanpassen, en niet alles wat er binnen ligt. We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar dat is niet het primaire doel van deze import. Grenzen verbeteren is trouwens een piece of cake vergeleken met het importeren van alle adressen. Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden van de adressen. Iedere mapper is natuurlijk vrij te doen wat hij wil. Groeten, Sander Op 30 oktober 2014 09:10 schreef Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Hey, 2014-10-30 8:41 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: Wat mij betreft is een adres niet compleet, zonder postcode en gemeente. Ik ben het hiermee eens. Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, gemeente. Associated street klinkt logisch en best vertrekkende vanuit kennis van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is dat we nodig hebben is meer mappers. Werken met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt met werken als er een boundary kapot gaat (en dan zijn ineens alle adressen daar waardeloos), als een gebouw adres op/dichtbij de grens ligt (denk aan een perceel dat grotendeels in één gemeente ligt maar het gebouw in een andere?!). Ik heb heel veel ervaring met adressen vanuit mijn werk bij de post en AGIV en boundaries kloppen niet altijd, adressen kloppen niet altijd, locaties van adressen zijn niet altijd logisch tov straatnaam/postcode en/of gemeente! Er zijn zelfs adressen die enkel te onderscheiden zijn op gemeente naam (dus postcode,straat, nummer is NIET overal uniek). Als dat zo gebeurt, dan moeten we zorgen dat we die nodes niet mergen in de tools. Maar op zich is het geen probleem dat die ene straat 2 keer hetzelfde huisnummer heeft. De vergelijkingstools zullen ook niet zo werken als het moet tenzij een max afstand ingegeven is. Maar ik denk niet dat er veel dergelijke straten zijn. De boodschap is: keep it simple! Iets relatiefs eenvoudig als een adres moet in OSM ook eenvoudig blijven om
Re: [OSM-talk-be] import AGIV CRAB-data
Natuurlijk zijn er problemen met adressen. Iedereen kent probleemadressen. Maar werken met relaties zorgt ongetwijfeld voor fouten (iedereen maakt fouten). Het wordt enkel maar erger als je 200 relaties moet onderhouden voor 1 gemeente. Terwijl je hier ook, voor alle gevallen de gegevens perfect kan afleiden van de grenzen. Natuurlijk kan het met een grens fout lopen, als iemand die onderbreekt of verschuift. Maar het onderhouden van een grens is maar 1 relatie per postcode, gemeente of deelgemeente. Ook met het taggen van objecten loopt het soms fout. Gelukkig doet JOSM altijd suggesties, maar soms kan je met een verkeerde Tab-Enter actie ook wel de verkeerde tag toevoegen. Hoe meer tags, hoe meer er verkeerd kunnen zijn. Ik kan begrijpen dat je die relaties of extra tags wil toevoegen voor de moeilijke gevallen (om zo een beter overzicht te krijgen), als je echter voor alles relaties en/of extra tags toevoegt, dan verlies je opnieuw het overzicht door de vele relaties die niet nodig zijn. Zelf heb ik ook ooit alles met A-S relaties gedaan. Maar daar ben ik van afgestapt. Mijn dorp was gewoon niet meer te onderhouden omdat er veel te veel A-S relaties waren in de selectielijst. Het is al een eindje dat ik geen nieuwe A-S relaties meer maak, en sinds kort verwijder ik ook de A-S relaties in de straten die ik update. Met taggen heb ik dezelfde fouten gemaakt. Een hoop is_in tags zijn nog altijd te vinden. Ook deze verwijder ik nu als ik ze tegenkom. Groeten, Sander Op 30 oktober 2014 13:13 schreef Jo winfi...@gmail.com: Ziehier een prachtvoorbeeld van hoe scheef het kan lopen: https://www.openstreetmap.org/relation/1523419/history https://www.openstreetmap.org/relation/1523417/history https://www.openstreetmap.org/relation/1524225/history Maar wat wil je dan op een grens tussen de provincies... Vooral deze huizen (14 en 15) lijken mij bijzonder lastig om te vinden: https://www.openstreetmap.org/node/1495908473/history Die straat is dus op een bepaald gedeelte aan de ene kant doorlopend genummerd en aan de andere kant even/oneven met een andere reeks nummers en ze heet tegelijk Langstraat en Langestraat op die gedeeltes. Dankzij die relaties is het meteen duidelijk hoe de vork aan de steel zit. Jo Op 30 oktober 2014 12:20 schreef Glenn Plas gl...@byte-consult.be: Ik deel die mening ook over die relaties. En zeker over interpolation van adressen in Belgie springt het van tijd wel heel hard, ik weet een straat waar huizen naast elkaar opeenvolgende nummers krijgen, bv 1,2,3,4,5 8 Dus geen even/oneven verdeling zoals we gewoon zijn. Geocoding werkt ook gewoon beter met de klassieke adress tagging, dit is vooral vanuit mijn eigen ervaring met nominatim servers te bouwen. Glenn On 30-10-14 11:57, Sander Deryckere wrote: Ik heb gewoon conceptuele problemen met associatedStreet relaties. Wanneer stopt een straat? Stop een straat aan iedere postcode of gemeentegrens? Wat doe je als de nummering verder loopt, is dat dan niet dezelfde straat? Krijg je geen problemen als je ziet dat onze grenzen verkeerd waren, en er bepaalde huizen blijken in andere gemeentes te liggen? Dus ga ik akkoord met Ben: Keep it simple, maar net iets anders. Gewoon straatnaam en huisnummer op het gebouw, de rest kan afgeleid worden uit de grenzen. Als die grenzen verkeerd blijken, dan moeten we slechts die grenzen aanpassen, en niet alles wat er binnen ligt. We kunnen de data van CRAB ook gebruiken om de grenzen te verbeteren, maar dat is niet het primaire doel van deze import. Grenzen verbeteren is trouwens een piece of cake vergeleken met het importeren van alle adressen. Het onderhouden van boundaries is ook veel eenvoudiger dan het onderhouden van de adressen. Iedere mapper is natuurlijk vrij te doen wat hij wil. Groeten, Sander Op 30 oktober 2014 09:10 schreef Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Hey, 2014-10-30 8:41 GMT+01:00 Jo winfi...@gmail.com mailto:winfi...@gmail.com: Wat mij betreft is een adres niet compleet, zonder postcode en gemeente. Ik ben het hiermee eens. Ge moet ook bedenken dat we in OSM niet persé het meest efficiënte data-model moeten hebben. Een deel van de prioriteit zou ook moeten zijn dat de dingen gemakkelijk onderhoudbaar zijn daarom ben ik voorstander van de meest eenvoudige oplossing in de vorm van adressen met straat, nummer, postcode, gemeente. Associated street klinkt logisch en best vertrekkende vanuit kennis van IT, GIS, JOSM, database normalisatie en dergelijke maar ik wil niet diegene zijn die dat moet gaan uitleggen aan nieuwelingen. En als er nu één ding is dat we nodig hebben is meer mappers. Werken met boundaries voor postcode/gemeente klinkt ook goed maar dat stopt met werken als er een boundary kapot gaat (en dan zijn ineens alle
Re: [OSM-talk-be] import AGIV CRAB-data
2014-10-30 14:02 GMT+01:00 Marc Gemis marc.ge...@gmail.com: Langestraat 14, Baal Vreemd toch die nominatim: Langestraat 14, Tremelo werkt dan weer wel! (op osm.org op de nominatim-website dan weer niet) Ik heb nominatim altijd een vreemd beest gevonden. Het is volgens mij of een kwestie van tijd voor verdere verbeteringen of anders gaat die volledig vervangen worden door iets nieuw. Dat kan zo niet blijven duren. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
2014-10-30 14:31 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com: Langestraat 14, Tremelo Nominatim gebruikt de associatedStreet enkel en alleen om een straatsegment te zoeken. Het neemt gewoon de eerste street in de relatie (verklaart misschien de afwijkende resultaten op de 2 sites, als die 2 databanken hebben). Verder kijkt het waar die straat ligt, binnen welke grenzen. Het kijkt niet naar de attributen op de relatie (zoals Jo wil). Misschien is associatedStreet een goed instrument voor dit, maar kijk maar eens op het Duitse forum, de Engelse mailing list. Niemand wil dat ding. Dus is het IMHO twijfelachtig dat de opvolger daar wel naar gaat kijken. Omdat Nominatim nu ook niet kijkt naar de attributen op het adrespunt zelf (buiten huisnr), is er voor de Langestraat 14 (en vele andere gevallen) geen goede tagging methode. Maar misschien dat een andere geocoder wel iets zinnig doet met die attributen op de node/gebouw. mvg m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Probeer eens op deze: http://nm1.bitless.be/ Is een oudere export met eigen customizations van mezelf. Glenn On 30-10-14 14:46, Marc Gemis wrote: 2014-10-30 14:31 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Langestraat 14, Tremelo Nominatim gebruikt de associatedStreet enkel en alleen om een straatsegment te zoeken. Het neemt gewoon de eerste street in de relatie (verklaart misschien de afwijkende resultaten op de 2 sites, als die 2 databanken hebben). Verder kijkt het waar die straat ligt, binnen welke grenzen. Het kijkt niet naar de attributen op de relatie (zoals Jo wil). Misschien is associatedStreet een goed instrument voor dit, maar kijk maar eens op het Duitse forum, de Engelse mailing list. Niemand wil dat ding. Dus is het IMHO twijfelachtig dat de opvolger daar wel naar gaat kijken. Omdat Nominatim nu ook niet kijkt naar de attributen op het adrespunt zelf (buiten huisnr), is er voor de Langestraat 14 (en vele andere gevallen) geen goede tagging methode. Maar misschien dat een andere geocoder wel iets zinnig doet met die attributen op de node/gebouw. mvg m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Deze ookal: http://maps.skobbler.com/?country=Belgiumcity=tremelostreet=Langestraatnumber=14lat=51.0244385lon=4.7465014z=16 Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ik speel al lang met het idee om een light weight straightforward geocoder te maken omdat nominatim te zwaar is, de hele PHP code is vergeven van uitzonderingen , afhankelijk van welke diepte level je zit. 5 jaar geleden moest ik de postcodes er nog bijhacken omdat die voor belgie niet meekwam als je zelf nominatim opzette (terwijl de indertijd gazetteer/nominatim het wel kon). Mijn interesse is vooral voor reverse geocoding (professioneel dan), maar het moet gewoon simpeler kunnen dan hoe het is nu. Uw 3 punten zijn wat mij betreft al de functionele analyse ervan. Glenn On 30-10-14 15:10, Ben Abelshausen wrote: Geen enkele geocoder is correct, heb er toch wel een 5-6 tal getest. Toch zeker niet als je dit opgeeft: Langestraat 14, Tremelo. Het grote nadeel is dat ze allemaal nominatim gebruiken als is alleen als pre-processing stap. Een duidelijke monocultuur als het geocoding aankomt. Ik begrijp het niet goed, wat we nu ook overeenkomen, en of Jo nu associatedStreets toevoegd of niet, die adressen zijn toch over het algemeen eenduidig af te leiden: - 1: Neem tags op node/gebouw eerst. - 2: Gebruik associated street tags als stap 1 niet werkt. - 3: Gebruik boundaries voor de vermiste informatie. Of zie ik het nu zo verkeerd? Ik heb zeker interesse in wat jullie hiervan denken omdat het ook op mijn agenda staat om een poging te doen begin volgend jaar. Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Bon, De CRAB herkomst staat nu altijd als odbl:note=CRAB:xxx, en kan dus gebruikt worden in de CSS. De webpagina is ook aangepast met twee extra opties. Zo kan je nu de CRAB herkomst ook zichtbaar meekrijgen (voor degene die het willen bekijken), en kan je ook de postcode als tag toevoegen. Let er op dat die postcode behandeling nog maar tijdelijk is, en mogelijks buggy. De echte code voor die optie kan er maar komen als de CRAB data vernieuwd is. Groeten, Sander 2014-10-30 15:13 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com: Deze ookal: http://maps.skobbler.com/?country=Belgiumcity=tremelostreet=Langestraatnumber=14lat=51.0244385lon=4.7465014z=16 Met vriendelijke groeten, Best regards, Ben Abelshausen ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Wil je beide lijsten (busnrs en apptnrs) los in de JSON hebben, of samengevoegd als “subadressenlijst”? Ik had het als dat laatste al ingebouwd, maar ik kan het natuurlijk eenvoudig weer uit elkaar trekken. De lijsten worden toch al los van elkaar opgebouwd. Groeten, Thomas Sander Deryckere schreef op 29-10-2014 12:06: Hoi Thomas, Net het script wat verder aangepast voor de nieuwe data, en geuploaded naar jouw repo. Dus aan iedereen, gelieve vanaf nu vooral http://aptum.github.io/import.html te testen, Kan je de appartementsnummers en busnummers als aparte lijsten in de JSON zetten? Dan kan ik ook het script updaten om addr:flats te ondersteunen. Lijsten zijn het best aangezien ze gemakkelijker omgevormd kunnen worden naar de correcte formaat. Ook die best alfabetisch sorteren voor de diffs. En misschien enkel de lijsten aan de JSON toevoegen indien wel degelijk (dat zal bandbreedte sparen voor de vele adressen die geen busnummers of appartementsnummers hebben). Aangezien de overlappende en de niet overlappende nummers nu in verschillende kolommen staan, is daar geen verschillende CSS voor nodig. Een verschillende CSS voor de herkomst kan wel helpen. Momenteel staat die herkomst nog in CRAB:source om de waarden gemakkelijk te kunnen aflezen. Dus momenteel die tags nog niet gaan uploaden. Als het goed is voor iedereen, dan breng ik die tags naar de vorm * odbl:note=CRAB:manueleAanduidingVanGebouw * odbl:note=CRAB:geinterpoleerdObvNevenliggendeHuisnummersGebouw * ... odbl:note lijkt mij de meest neutrale van alle discardable tags, en het voorvoegsel CRAB: kan zorgen voor unieke CSS selectors. De grootste problemen momenteel zijn de huisnummers met een underscore. Ik kan moeilijk beslissen als ik die naar bis, ter, ... of naar /1, /2, /3, ... breng. Maar het overlaten aan de mapper kan er voor zorgen dat de huisnummers met een underscore rechtstreeks geuploaded worden. Het andere grote probleem is de spelling van de straatnaam. Dat is moeilijk om af te leiden met de beperkte OSM data die ik heb in de webpagina (vooral als er nog geen adressen in OSM zijn). Een spellingsverschil kan er voor zorgen dat huisnummers geuploaded worden waarbij addr:street verschilt van de straatnaam in OSM. Wat natuurlijk voor problemen zal zorgen. Maar hierbij kan Jo misschien helpen, of de JOSM validator. Als die problemen opgelost zijn, dan lijken de tools klaar, en wordt het tijd om enkele definitieve beslissingen te maken: * Huizen tekenen of niet * Aparte gebruikersnaam of niet * Welke tags moeten op de changeset * Hoe contacteren we het AGIV met opmerkingen? * ... Groeten, Sander Op 29 oktober 2014 08:39 schreef Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: Nog niet, eerst onze tools maken, dan kunnen we het opnieuw presenteren. Groeten, Sander Op 29 oktober 2014 05:08 schreef Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com: Hoe zit het met het nodige papierwerk rond de import ? Zijn daar al vorderingen gemaakt ? groeten m 2014-10-26 13:18 GMT+01:00 Thomas o...@aptum.nl mailto:o...@aptum.nl: De code staat op https://github.com/aptum/aptum.github.io. De code van het python-conversiescript staat er nog niet op omdat ik nog wat dingen aan het omschuiven ben. Ik probeer dat script zo snel mogelijk ook daarbij te zetten. De nieuwste variant van het javascript en de website (met uitzondering van die twee regels code om 'mijn' tag in JOSM in te laden; regels 358-359) kun je bij Sander vinden: https://github.com/sanderd17/sanderd17.github.io/ Het inladen van gegevens uit de overpass is op zich wel mogelijk, maar we moeten denk ik wel heel erg opletten dat het geen allegaartje wordt. CRAB en OSM strikt gescheiden houden heeft misschien ook wel voordelen; tenzij je een specifiek doel voor ogen hebt? Groeten, Thomas Jo schreef op 26-10-2014 12:58: Hallo Thomas, Waar staat de broncode nu? Ik had het graag nog 's bekeken. Ook de JS die ik de vorige keer gemist heb... Is er een mogelijkheid om wat je afhaalt met Overpass ook mee te geven naar JOSM? Of is dat niet zo'n goed idee. Van zodra duidelijk is welke discardable tags je gebruikt, zal ik een MapCSS-stijl maken. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl mailto:o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt.
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb het script nu verder uitgerust met een aantal data-integriteits-checks rond postcode / gemeente. Daaruit blijken toch nog wat bijzondere dingen waar ik het script op moet aanpassen. Zo blijkt dat een straat (zoals geïdentificeerd door zijn ID in de adressenlijst) in meerdere postcodes kan voorkomen, maar nooit in meerdere gemeenten. Een gemeente bestaat uiteraard uit meerdere postcodes. Daarnaast kan 1 postcode zich in meerdere gemeenten bevinden. Halleluja; lees deze alinea nog maar 3 keer opnieuw... Op dit moment identificeren we op basis van postcode → straat. Dat houdt in dat we nu een aantal straten splitsen over de postcode, terwijl we op basis van de data die straten zouden kunnen samenhouden. Mogelijk (nouja; dat ben ik wel zeker) zijn straten ook gesplitst op gemeentegrenzen, maar deze dataset biedt daar geen mogelijkheden voor. Mijn script pikt nu deze over-postcodes-heen-gesplitste-straten op; het gaat om 1920 unieke straten die meestal over 2 maar soms over 3 postcodes heen gesplitst zijn. Mijn script biedt al heel wat mogelijkheden om hier mee om te gaan, maar we moeten het natuurlijk wel eens zijn over wat wenselijk is. Concreet betekent het in feite dat als we onderscheid maken op basis van een postcode, we onherroepelijk straten zullen splitsen. We kunnen ervoor kiezen om de data per gemeente te ordenen, maar dan wordt de hoeveelheid data per gemeente bijna 2 keer zo groot als de data nu per postcode (er zijn in totaal 308 gemeenten en 519 postcodes). Gezien de nu vaak al grote hoeveelheid straten per postcode is dit misschien onwenselijk. Zeker omdat het volgens mij vaak al de stedelijke gemeenten zijn die meerdere postcodes hebben. Die gemeenten gaan dan van zeer grote stratenlijsten naar enorme stratenlijsten. Een alternatief is die straten in beide postcodegebieden op te nemen. Dat vind ik ook geen nette uitwerking omdat je dan redundancy krijgt in de de JSON-bestanden. Volgens mij is dan de beste optie om per straat in de postcode-JSON-bestanden een extra JSON-attribuut mee te geven die aangeeft of de straat doorloopt in een andere gemeente. Dat zie ik in de vorm van een lijst van postcodes per straat waar de straat in doorloopt. Dat kan met wat javascript uitgelezen worden. Die specifieke straat kan in datzelfde stuk javascript opgehaald worden en aan de betrokken straat toegevoegd worden. Als je het meer handmatig wil houden kun je vrij eenvoudig een knop toevoegen voor de gebruiker om die straat in de andere gemeenten mee in te laden. Op deze manier kan de opdeling per postcode gehandhaafd worden, maar is toch duidelijk op straat-niveau waar mappers mee rekening dienen te houden. Daarnaast is deze informatie mogelijk ook zeer belangrijk voor de scripts van Jo rond het koppelen van adressen/gebouwen aan een straat. Wat denken jullie hiervan? Daarnaast speelt dus het tweede punt dat er een aantal postcodes over meerdere gemeenten heen lopen. Althans: dat er adrespunten zijn met dezelfde postcode die tot een andere gemeente behoren. Voor mijn script en onze opzet is dat op zich geen probleem, maar ook hier kan ik deze punten specifiek eruit lichten. Het gaat overigens 54 van de 519 postcodes; toch zo'n 10%. Daarbij zijn 81 gemeenten betrokken; een kwart van het totaal aantal gemeenten. Het totaal aantal adrespunten draait zo rond de 250 adrespunten in totaal. Ik moet mijn script nog wat aanpassen om preciese cijfers hierover te hebben. Ruimtelijke samenhang is er niet: het komt nergens in aanzienlijk grotere mate voor dan elders. Hoewel soms gesteld wordt dat postcodes helemaal niet samenvallen met gemeenten, blijkt dat dit dus maar in 1 op de 15.000 gevallen NIET zo is. Meestal gaat het over 1 postcode die over twee gemeenten valt. In 7 van de 54 gevallen gaat het om een postcode die binnen 3 gemeenten valt. Nooit gaat het om meer dan 3 gemeenten. Kort samengevat: op basis van de bij de adrespunten behorende gemeente kunnen we straten die door een postcode gesplitst worden weer aan elkaar plakken. Mijn idee is om een lijst van postcodes aan de straat te koppelen in de JSON, zodat in het javascript die gegevens verwerkt kunnen worden. Daarnaast zijn het postcodesysteem en de gemeentelijke indeling gescheiden systemen. Wordt daar in de verdere verwerking in OSM rekening mee gehouden? Onder andere bij de verschillende scripts die matching regelen is dat een belangrijk punt. Met mijn script kan ik “afwijkende” punten aangeven, maar dan moeten we wel weten op welke manier. Wat moeten we hiermee? Groeten, Thomas Sander Deryckere schreef op 29-10-2014 12:06: Hoi Thomas, Net het script wat verder aangepast voor de nieuwe data, en geuploaded naar jouw repo. Dus aan iedereen, gelieve vanaf nu vooral http://aptum.github.io/import.html te testen, Kan je de appartementsnummers en busnummers als aparte lijsten in de JSON zetten? Dan kan ik ook het script updaten om addr:flats te ondersteunen. Lijsten zijn het
Re: [OSM-talk-be] import AGIV CRAB-data
Misschien beter om de lijsten van appartementsnummers en busnummers te splitsen. Zelf begrijp ik het verschil nog niet goed, maar als we het eenmaal begrijpen, dan moet de data tenminste niet opnieuw gegenereerd worden. Op 29 oktober 2014 19:52 schreef Thomas o...@aptum.nl: Ik heb het script nu verder uitgerust met een aantal data-integriteits-checks rond postcode / gemeente. Daaruit blijken toch nog wat bijzondere dingen waar ik het script op moet aanpassen. Zo blijkt dat een straat (zoals geïdentificeerd door zijn ID in de adressenlijst) in meerdere postcodes kan voorkomen, maar nooit in meerdere gemeenten. Een gemeente bestaat uiteraard uit meerdere postcodes. Daarnaast kan 1 postcode zich in meerdere gemeenten bevinden. Halleluja; lees deze alinea nog maar 3 keer opnieuw... Op dit moment identificeren we op basis van postcode → straat. Dat houdt in dat we nu een aantal straten splitsen over de postcode, terwijl we op basis van de data die straten zouden kunnen samenhouden. Mogelijk (nouja; dat ben ik wel zeker) zijn straten ook gesplitst op gemeentegrenzen, maar deze dataset biedt daar geen mogelijkheden voor. Mijn script pikt nu deze over-postcodes-heen-gesplitste-straten op; het gaat om 1920 unieke straten die meestal over 2 maar soms over 3 postcodes heen gesplitst zijn. Mijn script biedt al heel wat mogelijkheden om hier mee om te gaan, maar we moeten het natuurlijk wel eens zijn over wat wenselijk is. Concreet betekent het in feite dat als we onderscheid maken op basis van een postcode, we onherroepelijk straten zullen splitsen. We kunnen ervoor kiezen om de data per gemeente te ordenen, maar dan wordt de hoeveelheid data per gemeente bijna 2 keer zo groot als de data nu per postcode (er zijn in totaal 308 gemeenten en 519 postcodes). Gezien de nu vaak al grote hoeveelheid straten per postcode is dit misschien onwenselijk. Zeker omdat het volgens mij vaak al de stedelijke gemeenten zijn die meerdere postcodes hebben. Die gemeenten gaan dan van zeer grote stratenlijsten naar enorme stratenlijsten. Een alternatief is die straten in beide postcodegebieden op te nemen. Dat vind ik ook geen nette uitwerking omdat je dan redundancy krijgt in de de JSON-bestanden. Volgens mij is dan de beste optie om per straat in de postcode-JSON-bestanden een extra JSON-attribuut mee te geven die aangeeft of de straat doorloopt in een andere gemeente. Dat zie ik in de vorm van een lijst van postcodes per straat waar de straat in doorloopt. Dat kan met wat javascript uitgelezen worden. Die specifieke straat kan in datzelfde stuk javascript opgehaald worden en aan de betrokken straat toegevoegd worden. Als je het meer handmatig wil houden kun je vrij eenvoudig een knop toevoegen voor de gebruiker om die straat in de andere gemeenten mee in te laden. Op deze manier kan de opdeling per postcode gehandhaafd worden, maar is toch duidelijk op straat-niveau waar mappers mee rekening dienen te houden. Daarnaast is deze informatie mogelijk ook zeer belangrijk voor de scripts van Jo rond het koppelen van adressen/gebouwen aan een straat. Wat denken jullie hiervan? Ik zie hier geen probleem in. Normaal moet een adres uniek zijn met postcode, straatnaam en huisnummer (het is toch op deze manier dat de Post - of bPost - brieven sorteert). Dus, hoewel een straat kan doorlopen in een andere postcode, kan het dan gebeuren dat de huisnummers niet meer uniek zijn (daar zijn genoeg voorbeelden van). Aangezien we noch de postcode, noch de gemeentenaam taggen, noch de straat indelen met een associatedstreet relatie, is het dus voor ons niet zo belangrijk als een straat nu over meerdere postcodes loopt, over meerdere gemeenten, of als postcode- en gemeentegrenzen niet overeenkomen. Het enige waar we moeten voor zorgen is dat alle adressen wel degelijk onder een postcode ondergebracht zijn, en dat we geen verschillende adressen mergen. Daarnaast speelt dus het tweede punt dat er een aantal postcodes over meerdere gemeenten heen lopen. Althans: dat er adrespunten zijn met dezelfde postcode die tot een andere gemeente behoren. Voor mijn script en onze opzet is dat op zich geen probleem, maar ook hier kan ik deze punten specifiek eruit lichten. Het gaat overigens 54 van de 519 postcodes; toch zo'n 10%. Daarbij zijn 81 gemeenten betrokken; een kwart van het totaal aantal gemeenten. Het totaal aantal adrespunten draait zo rond de 250 adrespunten in totaal. Ik moet mijn script nog wat aanpassen om preciese cijfers hierover te hebben. Ruimtelijke samenhang is er niet: het komt nergens in aanzienlijk grotere mate voor dan elders. Hoewel soms gesteld wordt dat postcodes helemaal niet samenvallen met gemeenten, blijkt dat dit dus maar in 1 op de 15.000 gevallen NIET zo is. Meestal gaat het over 1 postcode die over twee gemeenten valt. In 7 van de 54 gevallen gaat het om een postcode die binnen 3 gemeenten valt. Nooit gaat het om meer dan 3 gemeenten. Kort samengevat: op basis van
Re: [OSM-talk-be] import AGIV CRAB-data
2014-10-29 20:37 GMT+01:00 Sander Deryckere sander...@gmail.com: Zowel de postcodes als de gemeentes worden op basis van grenzen getekend. De straten als lijnen die binnen bepaalde van die grenzen liggen, en de adressen als punten die ook binnen bepaalde van die grenzen liggen. Aangezien dit project enkel focust op adressen, is het dus genoeg dat we het nummer en de straatnaam correct hebben. De rest zou al in OSM moeten zijn, en kan gecorrigeerd worden indien nodig. Een verkeerde postcodegrens kan ook een oorzaak zijn van een wrong adres, maar in dat geval moet gewoon de postcodegrens verbeterd worden. Ik heb mijn werk aan de post code grenzen stopgezet bij gebrek aan deelgemeente grenzen. De postcodes zouden er moeten inzitten voor Antwerpen, Oost-Vlaanderen en West-Vlaanderen. Voor Vlaams-Brabant heb ik maar enkele deelgemeente grenzen toegevoegd. Voor Limburg zijn er enkel de postcode grenzen die samenvallen met een gemeente. Daar is bij mijn weten geen enkele deelgemeente grens ingetekend (toch niet vorig jaar toen ik bezig was met de postcode grenzen). Met deze Overpass query kan je zien hoever ik ben geraakt. http://overpass-turbo.eu/s/5Gs mvg m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Veel van de adressen die als wrong worden aangegeven, zijn gewoon 8a ipv 8A. De vraag is nu standardiseren we op hoofdletters voor die letters, of maken we het script hoofdletterongevoelig? Jo Op 28 oktober 2014 00:07 schreef Sander Deryckere sander...@gmail.com: Wat de afwijking in Ieper (8900) betreft, het enige wat in mij opkomt is dat er een dikke 2 jaar geleden een grootschalige hernoem actie was: http://nieuwsblad.be/cnt/DMF20120213_113 Dat de huisnummers daardoor foutief zijn lijkt me iets heel eigenaardigs. Buiten Ieper herken ik geen specifieke probleemgevallen. Groeten, Sander Op 27-okt.-2014 23:50 schreef Sander Deryckere sander...@gmail.com: Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen idd handig zijn. Op 27-okt.-2014 22:27 schreef Thomas o...@aptum.nl: Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM); maar misschien denken jullie daar anders over. Daarnaast is het misschien ook vervelend dat die tags default niet weergegeven worden in JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt / te veel moeite om die tags aan te zetten in de configuratie, dan is het misschien ook een te groot risico dat diezelfde gebruikers die tags misschien wel zou opladen naar OSM. Hoe denken jullie hierover? Mijn mening is dat we enerzijds enkel proberen informatie toe te voegen die op de server hoort, en als dat niet mogelijk is, dat die info dan op een gebruikelijke tag zoals fixme of note komt te staan. Misschien hoogstens de hack gebruiken om een betere mapCSS te kunnen maken, maar niet om directe info aan de mapper te geven. Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere tag-naam is zo aangepast in het javascript. Let voor nu dus wel op dat je deze tags niet naar OSM upload! Ik heb nu volgende tags toegepast: 1) CRAB:huisnrlabel. Deze bevat het huisnummer-label
Re: [OSM-talk-be] import AGIV CRAB-data
Voor zover ik zie, zijn er 2 mogelijke bisnummer formaten in CRAB. Deze met alfabetische en deze met numerieke toevoegingen. Voor zover ik gezien heb, worden de alfabetische toevoegingen altijd als een hoofdletter geschreven, zonder scheidingssymbool (dus 7A en niet 7a of 7 A). De numerieke toevoegsels worden in CRAB altijd gescheiden met een underscore ( _, onderstreepje in het Nederlands ). De toevoegsels bis en ter worden ook als numeriek beschouwd, zo zal een huisnummer 10 bis vertaald worden naar 10_2 De schrijfwijze van numerieke toevoegingen vind ik ronduit lelijk voor elke toepassing. Er is ook niemand die zijn adres als ik woon in de Koestraat 10 onderstreepje 2 zal vermelden. Mensen spreken over 10 bis en 10 ter. Dus eender waar die 10_2 zal opduiken (Nomitatim, Mapnik, OsmAnd, ...) zal dit voor verwarring zorgen. Mijn gevoel is dus wat tegenstrijdig. Langs de ene kant wil ik de hoofdletters van CRAB altijd overnemen, langs de andere kant vind ik hun schrijfwijze van numerieke toevoegsels niet goed genoeg, en prefereer ik bis, ter of wat er ook zichtbaar is op de gevel. Groeten, Sander Op 28 oktober 2014 08:46 schreef Jo winfi...@gmail.com: Veel van de adressen die als wrong worden aangegeven, zijn gewoon 8a ipv 8A. De vraag is nu standardiseren we op hoofdletters voor die letters, of maken we het script hoofdletterongevoelig? Jo Op 28 oktober 2014 00:07 schreef Sander Deryckere sander...@gmail.com: Wat de afwijking in Ieper (8900) betreft, het enige wat in mij opkomt is dat er een dikke 2 jaar geleden een grootschalige hernoem actie was: http://nieuwsblad.be/cnt/DMF20120213_113 Dat de huisnummers daardoor foutief zijn lijkt me iets heel eigenaardigs. Buiten Ieper herken ik geen specifieke probleemgevallen. Groeten, Sander Op 27-okt.-2014 23:50 schreef Sander Deryckere sander...@gmail.com: Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen idd handig zijn. Op 27-okt.-2014 22:27 schreef Thomas o...@aptum.nl: Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in
Re: [OSM-talk-be] import AGIV CRAB-data
2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn van busnummers en appartementnummers op dat specifieke adrespunt. Deze gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker nu in de testfase) verhelderend werken. Er is een addr:flats tag die kan gebruikt worden ( http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys). Ik weet niet wat nu net het verschil is tussen een busnummer en een appartementsnummer, maar het is volgens mij objectieve, verifieerbare een geografische info, dus als die beschikbaar is, dan moeten we ze niet persé uit OSM weren. Het lijkt mij ook het beste om deze info te parsen en onder te brengen onder addr:flats, waarbij we geen onderscheid hoeven te maken tussen apartmentnrs of busnrs. Wellicht best wel sorteren en dan gescheiden door komma's zonder verdere spaties. Mijn eerste CRAB: crap is ondertussen (per ongeluk) doorgestuurd naar de server. Daar gaan zeker en vast nog meer ongelukken mee gebeuren. Verder werk ik aan een Pythonscript dat binnen JOSM werkt om te helpen bij het integreren van de CRAB-data met wat er reeds in OSM zit. Om zoveel mogelijk adressen automatisch te koppelen aan gebouwcontouren. Zo blijft er meer tijd over om de gebouwcontouren zelf dan nauwkeuriger in te tekenen. De MapCSS is bijna klaar. Ik heb ook een pythonscriptje gemaakt (eigenlijk Jython) dat jullie output omzet naar data met discardable tags en dat een associatedStreetrelatie aanmaakt. Waarbij hij ook meteen op zoek gaat naar straten met dezelfde naam. Het zou daarbij helpen om postcode en gemeente ook aangeleverd te krijgen in discardable tags. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb mij bezig gehouden met het maken van unit tests. De vele regexen zorgden vaak voor bugs die al eens vroeger opgelost waren. Er is ondertussen ook ondersteuning voor bis, ter en /1, /2, ... Ook straatnamen met een streepje verschil (Sint-Jansstraat en Sint Jansstraat) worden nu vergeleken. De dubbele huisnummers worden nu ook vergeleken op basis van het huisnrlabel (wat enkel zal werken met de data van Thomas). Een adres wordt dus als matching beschouwd indien het huisnummer van OSM overeenkomt met het huisnummer van CRAB, of met het huisnummerlabel van CRAB. Afhankelijk van de lokale situatie kan een mapper dan kiezen om meerdere samenvallende huisnummers te splitsen, of samen te laten. Beiden moeten herkend worden. Thomas, aangezien het duidelijk is dat we met de adressenlijst gaan verder werken, zou ik commit access kunnen krijgen voor jouw repo? Dan kan ik verder werken met jouw data, en kan mijn adres gesloten worden. Ik denk om de no-position lijst te vervangen door een lijst van samenvallende adressen (a.d.h.v het huisnummerlabel eenvoudig te bepalen). Dat is net zoals vroeger, een simpele splitsing tussen de gemakkelijke gevallen en de moeilijke gevallen, wat de productiviteit enkel maar ten goede kan komen. Daarvoor is natuurlijk jouw data nodig. Jo, een script dat straten met dezelfde naam zoekt is idd handig. Vooral met straten zonder adres valt dit moeilijk te controleren op de webpagina (tenzij ik een nieuwe overpass query maak, en de gebruikers nog wat langer moeten wachten). Dus is het maar al te gemakkelijk om bij een straat als Guido Gezellestraat de adressen met G. Gezellestraat te importeren. Dat is zeker iets wat we moeten voorkomen. Ik denk echter niet dat die associatedStreet relaties nodig zijn (en dan heb je ook de postcode niet nodig). Groeten, Sander Op 28 oktober 2014 14:44 schreef Jo winfi...@gmail.com: 2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn van busnummers en appartementnummers op dat specifieke adrespunt. Deze gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker nu in de testfase) verhelderend werken. Er is een addr:flats tag die kan gebruikt worden ( http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys). Ik weet niet wat nu net het verschil is tussen een busnummer en een appartementsnummer, maar het is volgens mij objectieve, verifieerbare een geografische info, dus als die beschikbaar is, dan moeten we ze niet persé uit OSM weren. Het lijkt mij ook het beste om deze info te parsen en onder te brengen onder addr:flats, waarbij we geen onderscheid hoeven te maken tussen apartmentnrs of busnrs. Wellicht best wel sorteren en dan gescheiden door komma's zonder verdere spaties. Mijn eerste CRAB: crap is ondertussen (per ongeluk) doorgestuurd naar de server. Daar gaan zeker en vast nog meer ongelukken mee gebeuren. Verder werk ik aan een Pythonscript dat binnen JOSM werkt om te helpen bij het integreren van de CRAB-data met wat er reeds in OSM zit. Om zoveel mogelijk adressen automatisch te koppelen aan gebouwcontouren. Zo blijft er meer tijd over om de gebouwcontouren zelf dan nauwkeuriger in te tekenen. De MapCSS is bijna klaar. Ik heb ook een pythonscriptje gemaakt (eigenlijk Jython) dat jullie output omzet naar data met discardable tags en dat een associatedStreetrelatie aanmaakt. Waarbij hij ook meteen op zoek gaat naar straten met dezelfde naam. Het zou daarbij helpen om postcode en gemeente ook aangeleverd te krijgen in discardable tags. Jo ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Over het beschikbaar maken van postcode en gemeentenaam: de postcode wordt reeds meegegeven in de JSON bestanden en de gemeentenaam kan daaraan worden toegevoegd. Met twee regels code heb ik dat voor elkaar. Echter, daarbij moet ik wel de nodige extra checks inbouwen voor de gemeente-id en de naam en de mate waarin deze 1 op 1 matchen om ook hierin eenduidigheid te garanderen. Daarnaast biedt dit ook de mogelijkheid om een extra verwantschap tussen gemeente en postcode te bestuderen. Zoals ik uit de voorgaande mails begrepen heb matchen die niet overal. Dat zorgt voor gesplitste straten met potentieel andere schrijfwijzen. In de suggestie van Jo om iets met straat-relaties te doen kan dit punt ook voor problemen zorgen. Mijn import-script kan deze gevallen signaleren. Daarmee kan weer een aanvullend stuk zekerheid over de kwaliteit van de brondata worden ingebouwd. In de discussie over discardable keys denk ik dat de sleutel ligt in het gebruik van de addr:flats tag die de lijst met busnummers/appartementnummers weergeeft. Het is namelijk die informatie die door de gebruikers echt gezien moet worden. Voor die functie is een discardable tag ook niet echt inzetbaar, juist omdat de informatie erin verborgen wordt voor de gebruiker. Met de lijst van busnr/apptnr is dat afgedekt. De rest kan dan inderdaad met een discardable key en wat mapCSS worden weergegeven. De CRAB:huisnrlabel kan als als tag weggehaald worden uit de javascript. Voorlopig kan dit in de JSON blijven staan. Op die manier kan de informatie gebruikt worden door het script van Sander om verder gegevens aan elkaar te matchen. CRAB:message verdwijnt dus met het toevoegen van de addr:flats. CRAB-source heeft weinig inhoudelijke betekenis en kan met een discardable-tag worden vormgegeven met mapCSS ter ondersteuning bij het mappen. De fixme-tag inzetten bij specifieke herkomsten is ook een goed idee, denk ik. Die afwijkende huisnummerlabels zijn toch iets bijzonders. Dat wijst toch op een vage integratie van verschillende databronnen. Mogelijk dat dat probleem verholpen wordt als alle gemeenten eenmaal hun adressenbestand gevalideerd hebben. Het standaardiseren van de letters is een lastige kwestie. Die functie inbouwen in het importeer-script is misschien niet heel handig, omdat het matchen met OSM sowieso in de javascript gebeurt. Dit standaardiseren op 2 plaatsen regelen lijkt me zeer onhandig. Daarom ben ik voorstander van de gegevens uit het CRAB niet te standaardiseren naar al dan niet met hoofdletter bij het omzetten naar de JSON bestanden. Ik weet niet hoe consistent de gegevens in OSM zijn op dit punt. Als nu al in OSM beide varianten voor komen, dan zal dat ook in de toekomst mogelijk heel lastig te vermijden zijn, denk ik. Maar dat hangt dus af van de huidige status van OSM en die ken ik niet. Verder deel ik de visie van Sander op de schrijfwijze. Het script dat Jo beschrijft om gemakkelijker de CRAB-gegevens te mergen met OSM lijkt mij ook zeer handig. Daarbij zou ik wel heel erg opletten met het inladen van informatie uit OSM in de laag die geïmporteerd wordt. Ook de tegenovergestelde handeling van het automatisch doorvoeren van informatie uit de import in de OSM-data-laag lijkt me 'gevaarlijk' omdat eventuele fouten dan weer lastig te spotten zijn. Een wizard die voor elk punt de match weergeeft en slechts een druk op de knop vereist om de tags over te laden lijkt me dan weer prima. Op welke manier zie jij die koppeling tussen de CRAB-adrespunten en de OSM-gebouwcontouren voor je? Het tweede script vind ik lastiger. Het omzetten van de tags vind ik risicovol omdat op die manier een derde parse plaatsvindt. Er zijn nu al twee omzettingen: CRAB → JSON → JOSM. Ik denk dat die alternatieve tags beter in de javascript gerealiseerd kunnen worden. De associatedStreet-relatie is voor zover ik begrijp toch wat controversieel vanwege de toegevoegde complexiteit en de problemen van beginnende mappers met relaties. Hoewel ik de meerwaarde van een dergelijke relatie zeker zie, is dit ook een extra verwevenheid tussen de brondata en OSM die met de hoogste voorzichtigheid moet worden toegepast. Ook de opmerking van Sander over de potentieel verkeerde relaties lijkt me een aandachtspunt. Wanneer het script hiermee rekening houdt lijkt het me potentieel een zeer waardevolle toevoeging! Ik ga nu mijn conversie-script aanpassen met de bovengenoemde wijzigingen mbt de tags en de extra informatie. Ik ga een stuk documentatie opstellen over de inhoud en de structuur van de JSON-bestanden zodat mensen die aan andere scripts werken die hierop aansluiten een duidelijke referentie hebben over het hoe en wat van de beschikbare data. Ik ga de extra controle inbouwen voor gemeente-postcode. Daarmee staat het conversie-script dan zo ongeveer op punt. Als dat eenmaal getest is plaats ik mijn conversiescript ook op github. Alle command-line interactie heb ik nu ook bijna op orde,
Re: [OSM-talk-be] import AGIV CRAB-data
Hooi,s Bij de Balen Neetlaan wordt alles als missing opgegeven al is bijna alle in orde met de goede zonenummers. De huizen met pare nummers staan op Mol 2400, de onpare staan op Balen 2490. Voor beide gemeenten draagt de baan dezelfde naam. De gegevens komen wel fatsoenlijk binnen in JOSM. Bij Mol 2400 op het Beneluxplein staan veel missing maar het zijn allemaal garages. In de buurtstraten rondom zijn al de alleenstaande garages genummerd en worden als missings opgegeven. De link naar Sandert17 gaat voor het ogenblik niet meer. Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 27 oktober 2014 16:58 schreef Sus Verhoeven sus...@gmail.com: Hooi,s Bij de Balen Neetlaan wordt alles als missing opgegeven al is bijna alle in orde met de goede zonenummers. De huizen met pare nummers staan op Mol 2400, de onpare staan op Balen 2490. Voor beide gemeenten draagt de baan dezelfde naam. De gegevens komen wel fatsoenlijk binnen in JOSM. In OSM is de straat Balen Neetlaan en in CRAB is de straat Balen-Neetlaan. Met deze vorm van spellingsvariant heb ik nog geen rekening gehouden. Welke zou de correcte naam zijn? Moet ik hier zoals bij afkortingen over de verschillen kijken? Bij Mol 2400 op het Beneluxplein staan veel missing maar het zijn allemaal garages. In de buurtstraten rondom zijn al de alleenstaande garages genummerd en worden als missings opgegeven. Daar kan ik niets aan doen. Als CRAB zegt dat het een adres is, dan is het een adres. Maar ik weet niet als dat adres nu een woning, een garage of nog iets anders is. De link naar Sandert17 gaat voor het ogenblik niet meer. Oeps, sorry, is nu hersteld. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM); maar misschien denken jullie daar anders over. Daarnaast is het misschien ook vervelend dat die tags default niet weergegeven worden in JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt / te veel moeite om die tags aan te zetten in de configuratie, dan is het misschien ook een te groot risico dat diezelfde gebruikers die tags misschien wel zou opladen naar OSM. Hoe denken jullie hierover? Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere tag-naam is zo aangepast in het javascript. Let voor nu dus wel op dat je deze tags niet naar OSM upload! Ik heb nu volgende tags toegepast: 1) CRAB:huisnrlabel. Deze bevat het huisnummer-label zoals dat door het CRAB aangeleverd wordt. Het is een samengestelde waarde uit de huisnummers van (qua locatie) samenvallende adrespunten. 2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn van busnummers en appartementnummers op dat specifieke adrespunt. Deze gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker nu in de testfase) verhelderend werken. 3) CRAB:source. Deze had ik eerder al toegevoegd en bevat de herkomst van de gegevens. Ik heb de JSON-bestanden op mijn github-site bijgewerkt. Ik heb ook weer de laatste versie van Sander zijn JS-bestand overgenomen en er de tags aan toegevoegd. Alles staat nog steeds op http://aptum.github.io/import.html Groeten, Thomas Sander Deryckere schreef op 27-10-2014 11:55: Ik heb een sorteermogelijkheid toegevoegd aan het JS script (door op de headers te klikken, moet de UI nog wat aanpassen om het duidelijker te maken), en ik heb ook nog een issue opgelost met de huisnummervergelijking. Zo werd in het vorige script nummer 241 niet gemarkeerd als missing indien 24 of 41 van die straat in OSM bestond. Wat natuurlijk verkeerd was. Aangezien de meeste straten ofwel bijna
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb in JOSM de display.discardable-keys eens even terug op false gezet. MapCSS blijft deze wel tonen, ook al verschijnen ze dan niet meer in de Properties aan de rechterkant. Het beste van 'both worlds' lijkt me. Ze staan uit het zicht, worden zeker niet doorgestuurd naar de server en wie ze wil zien, ziet ze via MapCSS direct bij het adresobject in de grafische editor. Zou het mogelijk zijn om ook het postnummer en de gemeentenaam in zulke discardable keys te zetten? Dat het om tags gaat die niets met CRAB te maken hebben, maakt niet zoveel uit. Verlangen van iedereen die zich met deze integratie/import gaat bezighouden dat ze niet zouden vergeten om alle crab:* manueel te verwijderen, lijkt mij alleszins geen goed idee. Ik zal het waarschijnlijk zelf de helft van de tijd gewoon vergeten. Aan de JOSM-ontwikkelaars vragen om een aantal specifieke multiple purpose discardable keys te voorzien (discard1, discard2, enz) is wel een goed idee op langere termijn, maar dan moet je ook de Merkaartor, iD, Vespucci en Potlatchontwikkelaars meekrijgen. Gewoon tiger:source, CRAB:source odbl, CRAB:huisnrlabel. odbl:note, CRAB:message yh:LINE_NAME,gemeente yh:TYPE, postnummer gebruiken is veel simpeler. Jo Op 27 oktober 2014 22:26 schreef Thomas o...@aptum.nl: Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM); maar misschien denken jullie daar anders over. Daarnaast is het misschien ook vervelend dat die tags default niet weergegeven worden in JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt / te veel moeite om die tags aan te zetten in de configuratie, dan is het misschien ook een te groot risico dat diezelfde gebruikers die tags misschien wel zou opladen naar OSM. Hoe denken jullie hierover? Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere tag-naam is zo
Re: [OSM-talk-be] import AGIV CRAB-data
Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen idd handig zijn. Op 27-okt.-2014 22:27 schreef Thomas o...@aptum.nl: Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM); maar misschien denken jullie daar anders over. Daarnaast is het misschien ook vervelend dat die tags default niet weergegeven worden in JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt / te veel moeite om die tags aan te zetten in de configuratie, dan is het misschien ook een te groot risico dat diezelfde gebruikers die tags misschien wel zou opladen naar OSM. Hoe denken jullie hierover? Mijn mening is dat we enerzijds enkel proberen informatie toe te voegen die op de server hoort, en als dat niet mogelijk is, dat die info dan op een gebruikelijke tag zoals fixme of note komt te staan. Misschien hoogstens de hack gebruiken om een betere mapCSS te kunnen maken, maar niet om directe info aan de mapper te geven. Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere tag-naam is zo aangepast in het javascript. Let voor nu dus wel op dat je deze tags niet naar OSM upload! Ik heb nu volgende tags toegepast: 1) CRAB:huisnrlabel. Deze bevat het huisnummer-label zoals dat door het CRAB aangeleverd wordt. Het is een samengestelde waarde uit de huisnummers van (qua locatie) samenvallende adrespunten. Deze tag is volgens mij niet nodig in het finale script. JOSM waarschuwt dat er overlappende nodes zijn, en ik denk nog altijd dat we zoveel mogelijk gebouwen moeten proberen te tekenen (en dus van de nodes enkel de tags overnemen). 2) CRAB:message. Deze bevat informatie over het al dan niet aanwezig zijn van busnummers en appartementnummers op dat specifieke adrespunt. Deze gegevens hoeven niet in OSM opgenomen te worden maar kunnen (zeker nu in de testfase) verhelderend werken. Er is een addr:flats tag die kan gebruikt worden ( http://wiki.openstreetmap.org/wiki/Key:addr:housenumber#Detailed_subkeys).
Re: [OSM-talk-be] import AGIV CRAB-data
Wat de afwijking in Ieper (8900) betreft, het enige wat in mij opkomt is dat er een dikke 2 jaar geleden een grootschalige hernoem actie was: http://nieuwsblad.be/cnt/DMF20120213_113 Dat de huisnummers daardoor foutief zijn lijkt me iets heel eigenaardigs. Buiten Ieper herken ik geen specifieke probleemgevallen. Groeten, Sander Op 27-okt.-2014 23:50 schreef Sander Deryckere sander...@gmail.com: Bedankt voor de updates, lijkt veelbelovend. Die extra statistieken kunnen idd handig zijn. Op 27-okt.-2014 22:27 schreef Thomas o...@aptum.nl: Inmiddels ben ik weer een heel stuk verder met het script. De memoryload heb ik terug kunnen brengen tot 1,1GB. De looptijd zit nu net boven een uur. Dat komt vooral omdat ik een aantal extra checks heb toegevoegd. Daarmee kan de integriteit van de data wat beter vastgesteld worden, nu en in de toekomstige updates van de lijst. Ook de sortering heb ik nu in orde gebracht. Concreet test ik nu of een straat-id inderdaad identificerend is voor een straatnaam. Ook houd ik wat gedetailleerder bij hoeveel appartementsnummers en busnummers het script negeert als adrespunt. Daarnaast heb ik in mijn ogen mogelijk zinvolle informatie toegevoegd aan de JSON-bestanden. Die informatie kan dan eenvoudig via het JS al dan niet, met welke tag dan ook, in JOSM geladen worden. Het gaat met name om een detailspecificatie van busnummers en appartementnummers die ook op dat adres geregistreerd zijn. Verder is er iets bijzonder aan de hand met de huisnummer-labels. Die worden door het AGIV automatisch opgemaakt per huisnummer, althans, zo hoort het. Toch heb ik met een check in mijn script 702 afwijkende huisnummerlabels weten te vinden. Die zijn gekoppeld aan 211 adressen, wat natuurlijk 'veel' is maar tegelijkertijd slechts 0,008% van het totaal. Daarbij in acht genomen dat 67% van die afwijkende huisnummerlabels zich voordoen in postcode 8900 lijkt het mij om een fout in de database te gaan. Wat er precies fout gelopen is op die punten weet ik niet. Ik heb de lijst op mijn server geplaatst: http://downloader.aptum.nl/AfwijkendeHuisnummerLabelsCRAB.pdf Wat daar aan de hand is moet dus even verder bekeken worden. Ik heb nu de informatie van de huisnummerlabels opgenomen in de JSON bestanden. Wanneer de huisnummerlabels voor alle sub-adressen bij 1 adrespunt (de busnummers en appartementsnummers) niet onderling gelijk zijn, wordt hier ook een melding van gemaakt en wordt de lijst met afwijkende huisnummerlabels doorgegeven via de JSON-bestanden. Als jullie even kunnen kijken of jullie punten op de lijst herkennen en weten wat specifiek daar speelt, dan kan dat heel erg helpen bij het begrijpen wat er precies fout loopt. Even wat cijfers over de adressenlijst: – 3.364.708 reccords – daarvan bevatten er 142.010 een appartementnummer en 583.913 een busnummer – zonder de subadressen, blijven er 2.639.893 unieke adrespunten over. – Er zijn 519 postcodes geregistreerd en 79185 straat-id's. Over welke tags te gebruiken twijfel ik nog wat. Enerzijds vind ik het een goed idee om discardable tags te gebruiken. Anderzijds (als ik de lijst daarvan in de broncode van JOSM bekijk: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java?rev=7643 regel 687 ev) zijn de huidige allemaal op een heel specifiek project gericht. Om zo'n bestaand label te 'verkrachten' met de informatie uit het CRAB vind ik niet helemaal netjes (ook al komen ze niet in OSM); maar misschien denken jullie daar anders over. Daarnaast is het misschien ook vervelend dat die tags default niet weergegeven worden in JOSM, terwijl het om informatie gaat die handig is / kan zijn voor de mappers. Aan de andere kant: als een gebruiker het te moeilijk vindt / te veel moeite om die tags aan te zetten in de configuratie, dan is het misschien ook een te groot risico dat diezelfde gebruikers die tags misschien wel zou opladen naar OSM. Hoe denken jullie hierover? Mijn mening is dat we enerzijds enkel proberen informatie toe te voegen die op de server hoort, en als dat niet mogelijk is, dat die info dan op een gebruikelijke tag zoals fixme of note komt te staan. Misschien hoogstens de hack gebruiken om een betere mapCSS te kunnen maken, maar niet om directe info aan de mapper te geven. Nu voorlopig heb ik toch even het CRAB:key-patroon gebruikt zodat ze in deze testfase voor iedereen helder zijn en netjes zichtbaar. Een andere tag-naam is zo aangepast in het javascript. Let voor nu dus wel op dat je deze tags niet naar OSM upload! Ik heb nu volgende tags toegepast: 1) CRAB:huisnrlabel. Deze bevat het huisnummer-label zoals dat door het CRAB aangeleverd wordt. Het is een samengestelde waarde uit de huisnummers van (qua locatie) samenvallende adrespunten. Deze tag is volgens mij niet nodig in het finale script. JOSM waarschuwt dat er overlappende nodes zijn, en ik denk nog altijd dat
Re: [OSM-talk-be] import AGIV CRAB-data
Sander of anderen, In Balen 2490, Hoolst zijn er plaatsen met een nummer op het gebouw en een ander nummer op het perceel. Moet ik hier de anomalieën in CRAB nog melden ? Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie kunnen op http://aptum.github.io/import.html mijn script testen. Het verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de adressenlijst in plaats van de adresposities. Uiterlijk is er niets veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het als er nog problemen gesignaleerd worden. Bij deze ook credits voor het vele en goede werk van Sander en voor het ter beschikking stellen van alle code! Groeten, Thomas Sander Deryckere schreef op 25-10-2014 21:17: Op 25 oktober 2014 20:57 schreef Thomas o...@aptum.nl mailto:o...@aptum.nl: Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat scheelt ook maar weer. De snelheid van mijn script valt me al bij al wel mee. Op dit moment gebruikt hij maar 1 thread. Het inlezen van het bestand in de dictionaries duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden een kleine 10 minuten (op een SSD'tje). Het schrijven gaat volgens mij wat trager omdat ik de adres-dictionary vervangen heb door een tuple. Dat scheelt toch een kleine 500MB in geheugengebruik. In totaal gebruikt het script maar iets van 2GB ram dacht ik, maar dat moet ik nog even nakijken. Sinds die wijziging heb ik in elk geval geen geheugenproblemen meer gehad.
Re: [OSM-talk-be] import AGIV CRAB-data
Op 26 oktober 2014 10:11 schreef Verhoeven Fr sus...@gmail.com: Sander of anderen, In Balen 2490, Hoolst zijn er plaatsen met een nummer op het gebouw en een ander nummer op het perceel. Moet ik hier de anomalieën in CRAB nog melden ? Sus Heb wat documentatie begonnen op de wiki pagina: https://wiki.openstreetmap.org/wiki/Talk:AGIV_CRAB_Import Zo hebben we een beter overzicht. Zou iedereen zijn fouten voorlopig daar kunnen melden? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Ik veronderstel dat ze ook een vage CRAB herkomst hebben? Zoals afkomstig van interpolatie in de straat? Dan kunnen die met CSS anders gekleurd worden om meer op te vallen. Het is ook zo dat niet de volledige straat in één keer geïmporteerd moet worden. Je kan eerst de duidelijke nummers importeren, en wachten met die probleemnummers tot de rest van de gemeente gedaan is. Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Dus dan heb je drie adressen, met de huisnummers 10, 12 en 14, en op elk van die adressen staat het huisnummerlabel 10-14? Ik denk dat die adressen toch sowieso gesplitst moeten worden, dus dat mergen niet moet. Maar we kunnen die info wel weer gebruiken om de huisnummers anders te markeren. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik zou het aan de mapper laten. Waarschijnlijk zullen de nummers meestal apart moeten blijven, dus lijkt het mergen niet zo'n goeie oplossing. Ik vraag me ook af, als je een apartement hebt met 1 adres en 10 busnummers, krijg je dan 1 keer het adres zonder busnummer, en dan nog 10 keer het adres met een extra busnummer? Of krijg je gewoon die 10 adressen met telkens een verschillend busnummer? In het eerste geval kan je gewoon alles wat een appartement- of busnummer bevat meteen vergeten in je Python script. In het tweede geval komt er weer een extra stap aan te pas om die te mergen. Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. In het vorige script had ik dat gewoon omzeild door direct met straatnamen te werken, en de id's gewoon niet te gebruiken om huisnummers te groeperen per straat. Dus als huisnummers tot dezelfde straatnaam behoorden (in dezelfde postcode), dan werden ze in dezelfde json gebracht. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie kunnen op http://aptum.github.io/import.html mijn script
Re: [OSM-talk-be] import AGIV CRAB-data
Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM. Ik zou dus die tags gebruiken ipv CRAB:source. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie kunnen op http://aptum.github.io/import.html mijn script testen. Het verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de adressenlijst in plaats van de adresposities. Uiterlijk is er niets veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het als er nog problemen gesignaleerd worden. Bij deze ook credits voor het vele en goede werk van Sander en voor het ter beschikking stellen van alle code! Groeten, Thomas Sander Deryckere schreef op 25-10-2014 21:17: Op 25 oktober 2014 20:57 schreef Thomas o...@aptum.nl: Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat scheelt ook maar weer. De snelheid van mijn script valt me al bij al wel mee. Op dit moment gebruikt hij maar 1 thread. Het inlezen van het bestand in de dictionaries duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden een kleine 10 minuten (op een SSD'tje). Het schrijven gaat
Re: [OSM-talk-be] import AGIV CRAB-data
Thomas, nog 1 opmerking. De pcode.json bestanden waren gesorteerd per naam (sanName om precies te zijn), en de straat.json bestanden werden lexicografisch volgens huisnummer gesorteerd (11-12-13-2-20-...). Dit is om dat op die wijze diffs in de toekomst meer zin zullen maken (en het formaat vanuit eender welke dataset na te bootsen is). Momenteel zijn de oude straten gesorteerd per alfabet, en zijn de nieuwe straten er achteraf aan geplakt. Dit formaat zal helaas niet te reproduceren vallen als ze ooit hun database formaat veranderen. Zou je dit ook willen toepassen? Groeten, Sander Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com: Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM. Ik zou dus die tags gebruiken ipv CRAB:source. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie kunnen op http://aptum.github.io/import.html mijn script testen. Het verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de adressenlijst in plaats van de adresposities. Uiterlijk is er niets veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het als er nog problemen gesignaleerd worden. Bij deze ook credits
Re: [OSM-talk-be] import AGIV CRAB-data
Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag worden geladen geen addr:housenumber/addr:street te gebruiken. Daar zou ik enkel discardable keys gebruiken, die we dan zichtbaar maken mbv MapCSS. (Wel Expert modus gebruiken, anders worden ze niet getoond) Zo ontstaat er geen verwarring bij het samenvoegen van die lagen. Als die nodes enkel discardable keys bevatten, zoals: tiger:upload_uuid, tiger:tlid, tiger:source, tiger:separated, geobase:datasetName, geobase:uuid, sub_sea:type, odbl, odbl:note, yh:LINE_NAME, yh:LINE_NUM, yh:STRUCTURE, yh:TOTYUMONO, yh:TYPE, yh:WIDTH_RANK)); dan worden die allemaal weggehaald en dan zal de validator daarover klagen. Even testen. Ai, de tags en hun waardes worden pas weggehaald na de validatie. Dat moet nog beter kunnen. Wat me ook belangrijk lijkt, is om voor die wrong-laag, upload=no aan te zetten in het XML-bestand: osm version=0.6 upload=no generator=Python/JS script changeset tag k=source v=CRAB/ /changeset Dan zal JOSM tenminste toch al klagen, als je die laag zonder meer zou proberen door te sturen. Met die changeset/source tags wordt spijtig genoeg geen rekening gehouden, voor zover ik kan zien. Maar toch lijkt het me wel goed om die toe te voegen. Jo Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com: Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM. Ik zou dus die tags gebruiken ipv CRAB:source. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee
Re: [OSM-talk-be] import AGIV CRAB-data
Op de Goudfazantenlaan in Heverlee wordt 5A als missing aangegeven. Dat nummer is er echter wel in OSM, maar dan als 5a. Willen we dit standaardiseren op allemaal hoofdletters, of willen we dat hoofdletterongevoelig houden? Jo Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com: Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM. Ik zou dus die tags gebruiken ipv CRAB:source. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten gelijk is, moeten deze dan automatisch worden samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter beoordeling van de mapper? Ik ga nog even kijken naar wat checks op die straatnamen met een gelijkaardige naam en een verschillende id. Het zou interessant zijn als die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal basis-integriteits-dingen toch al door het python-gedeelte mogen worden opgepikt. De loopduur van het script moet aan de andere kant ook weer zo kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) hebben geen of een zeer lage kost, terwijl deze toch een zekere basiskwaliteit van de dataset opleveren. De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst helder is. Ik heb de data van de laatste conversie alvast opgeladen samen met de webpagina en het JS. Aan de webpagina heb ik helemaal niets gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een conditional. Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster opbouwen. Misschien dat ik met een parallelle architectuur nog wat snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan worden. Ook alle problemen met de dataset die in de laatste mails gemeld werden ga ik nader bekijken. Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie kunnen op http://aptum.github.io/import.html mijn script testen. Het verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de adressenlijst in plaats van de adresposities. Uiterlijk is er niets veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het als er nog problemen gesignaleerd worden. Bij deze ook credits voor het vele en goede werk van Sander en voor het ter beschikking stellen van alle code! Groeten, Thomas Sander Deryckere schreef op 25-10-2014 21:17: Op 25 oktober 2014 20:57 schreef Thomas o...@aptum.nl: Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat
Re: [OSM-talk-be] import AGIV CRAB-data
De herkomst voor de punten die in mijn script samenvallen is vaak/meestal/altijd onderling niet verschillend, noch wijkt die herkomst af van de andere punten in de straat. Het gaat sowieso niet om busnummers / appartementnummers. Die heb ik net als in jouw script niet opgenomen. Het gaat steeds om verschillende adressen die dezelfde positie meegekregen hebben. Soms gaat het om verschillende nummers (vb 21 en 23) die samenvallen, soms om verschillende bisnummers (vb 25A en 25B) die samenvallen. Het zijn dus wel steeds echt verschillende adressen. In deze Adressenlijst vormt elke huisnummer-busnummer combinatie een eigen record. Stel: je hebt 2 huisnummers: nr 4 en nr 6. Beide behoren tot 1 gebouw. Voor beide nummers heb je 5 busnummers: bus1, bus2, bus3, bus4 en bus5. In de adressenlijst heb je dan 12 records (2 x 1 adres zonder busnummer en 2 x 5 adressen met busnummer). Het huisnummerr-label (HNRLABEL) is voor alle 12 records hetzelfde: “4-6”. In mijn script registreer ik (net zo als in het script van Sander) de adressen in een dictionary per straat met als key het huisnummer. Daarmee worden al die verschillende busnummer / appartementnummers genegeerd. Omdat de informatie verder toch gelijk is, is het overschrijven op basis van huisnummer als key in principe voldoende, en hoeft er verder niets gemerged te worden. Wat daar inhoudelijk moet gebeuren hangt af van de situatie ter plaatse, denk ik. Het meest handig is denk ik een FIXME-tag die aangeeft dat de punten samenvallen. Er moet immers steeds iets gebeuren met die punten. Daar kan dan eventueel het huisnummer-label aan worden toegevoegd, maar dat moeten we enkel doen als we dat een aanvaardbare situatie vinden (dat die punten worden samengevoegd tot 1 adres met zo'n samengesteld label). Als we dat samenvoegen in beginsel onwenselijk vinden (zo veel mogelijk los) dan moeten we dat label misschien juist niet aanleveren en enkel die FIXME-tag instellen. Dat sorteren heb ik over het hoofd gezien. Ik pas het aan; bij de volgende omzetting zal het weer netjes geordend staan. Het gebruiken van discardable keys is een goed punt; dat ga ik nog even verder bekijken. Ook het enkel gebruiken van discardable keys in de wrong-laag lijkt me een goed punt. Ook de upload=no ga ik toepassen. Dat is allemaal een beetje voer voor het javascript; daar heb ik nog maar weinig aandacht aan besteed. Ik pak het op. Verder is er nog iets gek aan de hand met het bepalen van de “Missing”-punten, zowel in mijn script als die van Sander. Voor veel plaatsen werkt dat prima. Nu keek ik naar postcode 9000, straat “Hoogpoort”. Daar lijkt het helemaal niet te werken (voor de hele postcode); niet bij jouw script en niet bij mijn script. In heel postcode 9000 (Gent) zou geen enkel “Wrong” punt zijn; dat kan niet. Mijn script levert geen “NoPos” punten op, dus dat is wel anders, maar de bestaande adressen in OSM worden niet opgepikt. Dat terwijl voor bijvoorbeeld postcode 8400 alles perfect gaat. Als ik de requests bekijk, krijgt JS netjes een JSON antwoord van overpass, maar voor postcode 9000 is die leeg (8400 is netjes gevuld). Dat doet me denken aan een soort timeout van je query. Handmatig het query invoeren levert overigens ook geen resultaten op. Misschien heeft het specifiek met Gent te maken, dat daar het selectiemechanisme om tot de postcode te beperken niet werkt of zo? Dat moeten we nog even goed bekijken. Overigens zag ik dat ik nog de oude variant van de webpagina en het JS-script gebruik. Die ga ik ook netjes updaten. Groeten, Thomas Jo schreef op 26-10-2014 11:41: Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag worden geladen geen addr:housenumber/addr:street te gebruiken. Daar zou ik enkel discardable keys gebruiken, die we dan zichtbaar maken mbv MapCSS. (Wel Expert modus gebruiken, anders worden ze niet getoond) Zo ontstaat er geen verwarring bij het samenvoegen van die lagen. Als die nodes enkel discardable keys bevatten, zoals: tiger:upload_uuid, tiger:tlid, tiger:source, tiger:separated, geobase:datasetName, geobase:uuid, sub_sea:type, odbl, odbl:note, yh:LINE_NAME, yh:LINE_NUM, yh:STRUCTURE, yh:TOTYUMONO, yh:TYPE, yh:WIDTH_RANK)); dan worden die allemaal weggehaald en dan zal de validator daarover klagen. Even testen. Ai, de tags en hun waardes worden pas weggehaald na de validatie. Dat moet nog beter kunnen. Wat me ook belangrijk lijkt, is om voor die wrong-laag, upload=no aan te zetten in het XML-bestand: osm version=0.6 upload=no generator=Python/JS script changeset tag k=source v=CRAB/ /changeset Dan zal JOSM tenminste toch al klagen, als je die laag zonder meer zou proberen door te sturen. Met die changeset/source tags wordt spijtig genoeg geen rekening gehouden, voor zover ik kan zien. Maar toch lijkt het me wel goed om die toe te voegen. Jo Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com mailto:winfi...@gmail.com: Voor
Re: [OSM-talk-be] import AGIV CRAB-data
Zo, even wat kwalitatief onderzoek gedaan: * De kwaliteit van de adressenlijst is over het algemeen beter, maar voor enkele huizen is het ook slechter. Zo heb ik de Ieperstraat in Staden (8840) bekeken, daar werd voor bepaalde huizen de positie in de adressenlijst net verder van de straat gezet (in de tuin), terwijl het net bij rijhuizen moeilijk is om de tuin te volgen en het juiste huis te vinden. Voor de meeste huizen ging het dan net omgekeerd en werd de positie dichter bij de straat gezet in de adressenlijst * Het probleem in de Mastbos straat is opgelost in de adressenlijst. Bij de Louisa-Marialaan blijft het probleem van dubbele huisnummers echter bestaan (hoe worden verwijderde huisnummers behandeld in de adressenlijst?) * Hoewel de herkomst soms aangeeft dat het afgeleid is van een gebouw, kan dit ook betekenen dat het afgeleid is van meerdere gebouwen. Zo kan een adres positie in het midden van een boerderij liggen, en niet op het hoofdgebouw. Als die boerderij dan nog eens 2 huisnummers heeft, dan wordt het helemaal onduidelijk. Dus is de adressenlijst meestal wel beter, maar ook soms minder goed. Bepalen welke de beste is, dat is programmatisch zo goed als onmogelijk. Aangezien 2 databases ondersteunen voor heel wat extra werk zal zorgen, stel ik momenteel voor om toch bij de adressenlijst te blijven, en de adresposities DB weg te negeren. De code zelf lijkt behoorlijk te werken. Enkel de sortering mankeert nog. De nummers van missing en wrong kolommen komen perfect overeen, en ook de accenten werken zonder probleem. Groeten, Sander Op 26 oktober 2014 11:41 schreef Jo winfi...@gmail.com: Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag worden geladen geen addr:housenumber/addr:street te gebruiken. Daar zou ik enkel discardable keys gebruiken, die we dan zichtbaar maken mbv MapCSS. (Wel Expert modus gebruiken, anders worden ze niet getoond) Zo ontstaat er geen verwarring bij het samenvoegen van die lagen. Als die nodes enkel discardable keys bevatten, zoals: tiger:upload_uuid, tiger:tlid, tiger:source, tiger:separated, geobase:datasetName, geobase:uuid, sub_sea:type, odbl, odbl:note, yh:LINE_NAME, yh:LINE_NUM, yh:STRUCTURE, yh:TOTYUMONO, yh:TYPE, yh:WIDTH_RANK)); dan worden die allemaal weggehaald en dan zal de validator daarover klagen. Even testen. Ai, de tags en hun waardes worden pas weggehaald na de validatie. Dat moet nog beter kunnen. Wat me ook belangrijk lijkt, is om voor die wrong-laag, upload=no aan te zetten in het XML-bestand: osm version=0.6 upload=no generator=Python/JS script changeset tag k=source v=CRAB/ /changeset Dan zal JOSM tenminste toch al klagen, als je die laag zonder meer zou proberen door te sturen. Met die changeset/source tags wordt spijtig genoeg geen rekening gehouden, voor zover ik kan zien. Maar toch lijkt het me wel goed om die toe te voegen. Jo Op 26 oktober 2014 11:09 schreef Jo winfi...@gmail.com: Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM. Ik zou dus die tags gebruiken ipv CRAB:source. Jo Op 26 oktober 2014 10:20 schreef Thomas o...@aptum.nl: De validator geeft inderdaad netjes melding van de meerdere punten op elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de adressen zonder positie uit jouw script vallen nu samen met een ander punt. Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel veel punten). Moeten we nog iets doen met een hulptag over appartementsnummer, busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het label het laagste en het hoogste huisnummer (bv. label 10-14 voor het perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook mogelijk moeten zijn om voor deze punten automatisch een samengestelde addr:housenumber-value te maken die een samenstelling is van de verschillende punten die samenvallen. Dat valt nog wel te coderen. Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat doen we met die samenvallende punten? Schuiven we de punten handmatig uit elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die punten niet wil mergen maar juist individueel houden. Het hele idee is ook dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen subadressen (busnummers en appartementnummers). Dus: indien de adrespositie voor twee adrespunten
Re: [OSM-talk-be] import AGIV CRAB-data
Hooi Sander, Hopelijk blijft uw tool as is beschikbaar. Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab data ligt in Leopoldsburg op de perceel-centroid, dus soms ver van de gebouwen, en de percelen zijn daar soms uitgestrekt. Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben, ( zoals bij OSM ;-) ), en er volgens de regio verschillen zitten. In Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen. Het enige opmerking is dat het huisnummer op de tagnode heel klein is en soms moeilijk leesbaar, althans op een netbook. Nogmaals bedankt. Sus Le 24/10/14 13:57, Sander Deryckere a écrit : Bah, Daar waar ik dacht dat we aan de eindspurt richting goeie tools bezig waren, staan we terug aan het begin. Na een maand programmeren. Ik heb nu even geen zin meer om het script van CRAB naar JSON te herschrijven voor die andere database structuur. Ik vind het goed genoeg zoals het is. Hebben we die enkele voordeurlocaties echt nodig? Enkel toegang tot de gebouwcontouren zou een echt nieuwe uitdaging geven (en met nut). Maar als iemand zin heeft om er verder aan te werken, de code is vrij om te forken. Mvg, Sander ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
Op 25 oktober 2014 09:21 schreef Verhoeven Fr sus...@gmail.com:
Hooi Sander,
Hopelijk blijft uw tool as is beschikbaar.
Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
gebeurt door Overpass of door je eigen computer.
Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij ingetekende
huizen te nummeren samen met de GRB gegevens. Al de Crab data ligt in
Leopoldsburg op de perceel-centroid, dus soms ver van de gebouwen, en de
percelen zijn daar soms uitgestrekt.
Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
( zoals bij OSM ;-) ), en er volgens de regio verschillen zitten. In
Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
soms moeilijk leesbaar, althans op een netbook
Dat kan opgelost worden met de mapCSS van Jo:
node[addr:housenumber]:new::
housenumber
{text-color: blue;
font-size: 25;
text: tag(addr:housenumber);
text-halo-radius: 2;
text-offset-y: 30;}
Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
huisnummers.mapcss. Dan ga je in JOSM naar View - Map pain styles - Map
paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
en laad je het huisnummers.mapcss bestand.
Als je nu de stijl aanvinkt onder View - Map paint styles, dan zullen de
huisnummers beter leesbaar zijn.
Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
de toekomst (waar we dan verschillende types misschien verschillende
kleuren kunnen geven).
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Ik heb het script even uitgeprobeerd en zie toch een paar rare dingen -
Misschien te wijten aan fouten in CRAB ?
Dit is het stukje van de kaart : http://osm.org/go/0ErRh7ZyY?m=way=70085786
.
Als ik het script laat lopen voor postcode 2440, street = Mastbos, dan
krijg ik Total = 19, Missing = 3, Wrong = 2.
Missing (nr 26) zou nog juist kunnen zijn, daar het een nieuwe wijk is en
er intussen een huis kan bijgekomen zijn dat nog niet op de luchtfoto's te
zien is. Ik zal deze namiddag eens ter plekke gaan kijken. Op de kaart van
AGIV staat echter geen huis getekend, wel een huisnummer. Als ik in JOSM
met de wms voor GRB-raadpleegdiensten de huisnummers (GRB-HNR_GBG) inlaad,
dan is nr 26 er niet bij. Als ik de perceelsnummers (GRB-HNR_ADP) inlaad
dan is nr 26 er als enige in die straat.
Bij de foute nummers geeft jouw script de nrs 15 en 17 op die resp. (=
missing) 71 en 41 zouden moeten zijn, alhoewel die huizen op de kaart van
AGIV wel degelijk als 15 en 17 genummerd zijn ? Als je de locatie met de
AGIV GDI viewer opzoekt (ik gebruik meestal geopunt.be) en je daar naar de
lijst van huisnummers kijkt, dab komen de nrs 71 en 41 ook helemaal niet
voor op de lijst.
2014-10-25 9:55 GMT+02:00 Sander Deryckere sander...@gmail.com:
Op 25 oktober 2014 09:21 schreef Verhoeven Fr sus...@gmail.com:
Hooi Sander,
Hopelijk blijft uw tool as is beschikbaar.
Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
gebeurt door Overpass of door je eigen computer.
Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij
ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab data
ligt in Leopoldsburg op de perceel-centroid, dus soms ver van de
gebouwen, en de percelen zijn daar soms uitgestrekt.
Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
( zoals bij OSM ;-) ), en er volgens de regio verschillen zitten. In
Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
soms moeilijk leesbaar, althans op een netbook
Dat kan opgelost worden met de mapCSS van Jo:
node[addr:housenumber]:new::
housenumber
{text-color: blue;
font-size: 25;
text: tag(addr:housenumber);
text-halo-radius: 2;
text-offset-y: 30;}
Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
huisnummers.mapcss. Dan ga je in JOSM naar View - Map pain styles - Map
paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
en laad je het huisnummers.mapcss bestand.
Als je nu de stijl aanvinkt onder View - Map paint styles, dan zullen de
huisnummers beter leesbaar zijn.
Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
de toekomst (waar we dan verschillende types misschien verschillende
kleuren kunnen geven).
___
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
Re: [OSM-talk-be] import AGIV CRAB-data
Op 25 oktober 2014 10:55 schreef Gilbert Hersschens gherssch...@gmail.com: Ik heb het script even uitgeprobeerd en zie toch een paar rare dingen - Misschien te wijten aan fouten in CRAB ? Dit is het stukje van de kaart : http://osm.org/go/0ErRh7ZyY?m=way=70085786. Als ik het script laat lopen voor postcode 2440, street = Mastbos, dan krijg ik Total = 19, Missing = 3, Wrong = 2. Missing (nr 26) zou nog juist kunnen zijn, daar het een nieuwe wijk is en er intussen een huis kan bijgekomen zijn dat nog niet op de luchtfoto's te zien is. Ik zal deze namiddag eens ter plekke gaan kijken. Op de kaart van AGIV staat echter geen huis getekend, wel een huisnummer. Als ik in JOSM met de wms voor GRB-raadpleegdiensten de huisnummers (GRB-HNR_GBG) inlaad, dan is nr 26 er niet bij. Als ik de perceelsnummers (GRB-HNR_ADP) inlaad dan is nr 26 er als enige in die straat. Bij de foute nummers geeft jouw script de nrs 15 en 17 op die resp. (= missing) 71 en 41 zouden moeten zijn, alhoewel die huizen op de kaart van AGIV wel degelijk als 15 en 17 genummerd zijn ? Als je de locatie met de AGIV GDI viewer opzoekt (ik gebruik meestal geopunt.be) en je daar naar de lijst van huisnummers kijkt, dab komen de nrs 71 en 41 ook helemaal niet voor op de lijst. Proficiat, je hebt net enkele nieuwe fouten ontdekt in die database ;) (let er trouwens op dat de vorm van die huizen op de GRB basiskaart wel zeer raar is). Die 26 zou ik niet als een fout zien. Soms krijgen bouwpercelen ook een huisnummer, en het is volgens mij niet fout om dat ook zo in OSM te zetten, elfs als er geen brievenbus is (misschien met een extra tag om het verschil te maken). In advertenties om die bouwgrond te verkopen kan dat onbebouwd perceel namelijk al aangeduid worden met dat huisnummer, en wanneer er wel een huis op komt, dan kunnen de eerste bewoners meteen vrienden ontvangen die de GPS gebruiken om het nieuwe huis te vinden ;) Maar die 71 en 41 zijn duidelijk fout. Ze komen ook rechtstreeks zo uit de adressen_posities database. Mogelijks staan die wel correct in hun adressen_lijst database. Het lijkt er meer en meer op dat die verschillende databases niet echt verbonden zijn, en dat ze elk afzonderlijk onderhouden worden. Als je wil, dan mag je dat melden aan AGIV, dan zullen ze het hopelijk aanpassen, en zal bij een volgende update het gecorrigeerd zijn. Het zou ook goed zijn om die fouten ergens te gaan documenteren, op de wiki bijvoorbeeld. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Hooi,
Het is gefixt dank zij de script van Jo uw de goede uitleg.
Ik gebruik het enkel om de CRAP gegevens op het scherm te krijgen. Als het
te ingewikkeld wordt zet ik gewoon niets in OSM.
Ze moeten maar bij de geburen gaan bellen. ;-)
Sus
2014-10-25 9:55 GMT+02:00 Sander Deryckere sander...@gmail.com:
Op 25 oktober 2014 09:21 schreef Verhoeven Fr sus...@gmail.com:
Hooi Sander,
Hopelijk blijft uw tool as is beschikbaar.
Momenteel wel, ik heb er geen kosten of onderhoud aan. Al het rekenwerk
gebeurt door Overpass of door je eigen computer.
Ik gebruik het nu in Leopoldsburg om de reeds vroeger door mij
ingetekende huizen te nummeren samen met de GRB gegevens. Al de Crab data
ligt in Leopoldsburg op de perceel-centroid, dus soms ver van de
gebouwen, en de percelen zijn daar soms uitgestrekt.
Ik heb ook al vastgesteld dat de AGIV mappers ook hun eigen stijl hebben,
( zoals bij OSM ;-) ), en er volgens de regio verschillen zitten. In
Agiv ligt het huisnummer, in dezelfde straat, soms op de gebouwen, soms op
de percelen, zonder vaste regel. Ik leg ze i, OSM op de gebouwen.
Het enige opmerking is dat het huisnummer op de tagnode heel klein is en
soms moeilijk leesbaar, althans op een netbook
Dat kan opgelost worden met de mapCSS van Jo:
node[addr:housenumber]:new::
housenumber
{text-color: blue;
font-size: 25;
text: tag(addr:housenumber);
text-halo-radius: 2;
text-offset-y: 30;}
Kopieer deze CSS code naar een tekst bestand, en noem het b.v.
huisnummers.mapcss. Dan ga je in JOSM naar View - Map pain styles - Map
paint preferences. Daar klik je rechts op het +-teken, geef je een naam in,
en laad je het huisnummers.mapcss bestand.
Als je nu de stijl aanvinkt onder View - Map paint styles, dan zullen de
huisnummers beter leesbaar zijn.
Let wel op, die CSS is nog voorlopig, en zal misschien verbeterd worden in
de toekomst (waar we dan verschillende types misschien verschillende
kleuren kunnen geven).
___
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
Re: [OSM-talk-be] import AGIV CRAB-data
Op 25 oktober 2014 11:38 schreef Gilbert Hersschens gherssch...@gmail.com: De vormen van de gevellijnen op GRB zijn heel onbetrouwbaar. Misschien gebaseerd op de oorspronkelijke bouwplannen? Ik gebruik de AGIV luchtfoto's en ga soms nog eens bij Bing kijken als ik er niet goed aan uit kan. Op geopunt.be kan je de adrespunten als afzonderlijke laag inladen. Volgen de GIS ambtenaar in Geel komen die rechtstreeks uit CRAB. Die geven de juiste nummers (15, 17) weer. Misschien gebruik jij niet de juiste adres velden van de DB ? Welke CRAB database? Adressen_positities, Adressen_lijst of xGrab? Het is natuurlijk altijd mogelijk dat ik een verkeerd veld genomen heb die in 99% van de gevallen toevallig overeenkomt met het huisnummer, en in de andere gevallen een niet-gerelateerd nummer geeft. Ik krijg ook nog andere rare fouten. Als ik de Aardseweg injlaad, dan geeft hij nagenoeg alle adressen als missing op terwijl die huizen wel degelijk (bijna) allemaal genummerd zijn ? Ik krijg 6 missing met positie en 3 zonder positie: http://sanderd17.github.io/import.html?pcode=2440filterStreets=Aard*maxDistance=loadOsm=true ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
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. Eigenaardig. Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Op 25 oktober 2014 14:48 schreef Sus Verhoeven sus...@gmail.com: 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. Eigenaardig. Sus Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers nog niet verwijderd zijn. 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. 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. 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. In Leuven werd onlangs een straat hernummerd (zie http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793) 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. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via einddatum. En blijkbaar gaat dat niet altijd samen. 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 :/ Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, en daar blijkt er nu geen verschil te zijn O_o Dus denk ik dat ik het script nog niet zal aanpassen. Groeten, Sander Op 25 oktober 2014 16:11 schreef Sander Deryckere sander...@gmail.com: Op 25 oktober 2014 14:48 schreef Sus Verhoeven sus...@gmail.com: 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. Eigenaardig. Sus Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers nog niet verwijderd zijn. 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. 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. 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. In Leuven werd onlangs een straat hernummerd (zie http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793) 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. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Le 25/10/14 16:11, Sander Deryckere a écrit : Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers nog niet verwijderd zijn. Ik vrrag mij zelfs af of men de naam niet verandert heeft. In Balen heeft men ook al hernummerd, maar daar stonden in AGIV 2 nummers. 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. Ja maar, ik heb geen hond om mee gaan te wandelen :-P En het ligt ook niet bij huis. Groetjes Sus ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] import AGIV CRAB-data
Dan lijkt het mij aangewezen om op die plek een Note achter te laten. Ik heb dat al hier en daar gedaan en al duurt het soms een paar maanden, uiteindelijk worden die wel gezien en opgelost. Jo Op 25 oktober 2014 18:37 schreef Verhoeven Fr sus...@gmail.com: Le 25/10/14 16:11, Sander Deryckere a écrit : Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers nog niet verwijderd zijn. Ik vrrag mij zelfs af of men de naam niet verandert heeft. In Balen heeft men ook al hernummerd, maar daar stonden in AGIV 2 nummers. 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. Ja maar, ik heb geen hond om mee gaan te wandelen :-P En het ligt ook niet bij huis. Groetjes Sus ___ 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
Re: [OSM-talk-be] import AGIV CRAB-data
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. 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. 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. 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. 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. 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. 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? Groeten, Thomas Sander Deryckere schreef op 25-10-2014 17:52: Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via einddatum. En blijkbaar gaat dat niet altijd samen. 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 :/ Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, en daar blijkt er nu geen verschil te zijn O_o Dus denk ik dat ik het script nog niet zal aanpassen. Groeten, Sander Op 25 oktober 2014 16:11 schreef Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com: Op 25 oktober 2014 14:48 schreef Sus Verhoeven sus...@gmail.com mailto:sus...@gmail.com: 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. Eigenaardig. Sus Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude nummers nog niet verwijderd zijn. 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. 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. 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. In Leuven werd onlangs een straat hernummerd (zie http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793) 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. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org
