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 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 volledig gemap zijn, ofwel bijna > niet, was deze fout moeilijk te vinden. Maar nu kan het dus zijn dat je > enkele extra "missing" adressen hebt. > > Thomas, pas jij het ook aan in jouw kopie? > > Groeten, > Sander > > Op 26 oktober 2014 22:02 schreef Sus Verhoeven <sus...@gmail.com>: > >> Hooi >> Met beide scripten heb ik hetzelfde probleem. Als ik de straat gegevens >> van de script eerst oplaadt in JOSM kan ik geen OSM kaart gegevens meer >> inladen in een apparte laag. Indien ik eerst de OSM gegevens inlaad kan ik >> wel elke straatgegevens in apparte lagen inladen. >> >> In 3970 Leopoldsburg liggen met de nieuwe script de huisnummers praktisch >> op dezelfde plaats dan in GRB, In Leopoldsbug lagen ze meestal op de >> perceelcentroid, dat is dus veel beter >> >> In de Koningsstraat krijg ik nu een nummer 40, maar die 40 wordt niet >> gevalideerd door Bpost. >> En volgens de foto en GRB is die moeilijk te verklaren >> Aan de overkant liggen er nog enkele nummers, wel volgens de foto's een >> terrein in aanbouw, Dat zou dus wel kunnen. Met de eerste schript lagen er >> daar veel meer. >> Zou het kunnen dat de mapccs van Jo niet meer werkt. ? >> Toch wel handig. >> >> Sus >> >> >> _______________________________________________ >> 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
