Is het misschien een idee om hier een keer een avond/middag voor bij elkaar te komen? Dat gaat alleen werken als de hoofdrolspelers allemaal aanwezig kunnen zijn natuurlijk.
Groet, Floris 2012/10/17 Floris Looijesteijn <[email protected]> > Ik zit ook te wachten op duidelijke regels voordat ik Haarlem ga > importeren, goed initiatief. > > Klein opmerking over de huisnummer toevoegingen. Waarschijnlijk kan de > toevoeging ook wel eens een nummer zijn. > Het zal niet de eerste keer zijn dat een pakketje bestemd voor 11 2 (of > 11-2) naar huisnummer 112 wordt gestuurd. > Dus minstens een spatie wat mij betreft. Of controleren of het alleen > letter is en de spatie weglaten. > > Ik ben benieuwd hoe de data voor mijn pand is, op mijn gevel hangt een > bordje met A terwijl men in Haarlem met 'Zwart' en 'Rood' werkt. > > Groet, > Floris > > 2012/10/17 Gertjan Idema <[email protected]> > >> ** >> Er is een aantal initiatieven gaande voor het opnemen van BAG data in >> Openstreetmap. >> - ruudblank heeft veel werk verricht in Gorinchem. >> - rullzer in de omgeving Purmerend >> - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee >> (Leusden) en Sebastiaan (Oldambt) nu kleinschalig >> aan het testen zijn. >> - en ongetwijfeld nog meer. >> >> Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee >> van deze discussie is om hier samen te vatten wat er tot nu toe gedaan en >> besproken is over het taggen van data afkomstig uit de BAG. Vervolgens hoop >> ik dat we het samen eens kunnen worden over een standaard. Deze kan dan >> opgenomen worden op de Wiki pagina en geïntegreerd in tools en scripts. Het >> doel hierbij is niet om zoveel mogelijk BAG dat in openstreetmap te >> krijgen, maar om te zorgen dat dit consistent gebeurt. >> >> Eerst maar eens een inventarisatie: >> >> Adres tags op pand of losse nodes >> ============================= >> De BAG maakt onderscheid tussen panden, verblijfsobjecten en >> nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten. >> Tot nu toe heb ik de adressen als volgt getagd: >> Voor panden met een enkel verblijfsobject heb ik de adres tags >> (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld met >> in tag "ref:bagid" het BAG id van het pand. >> Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen adres >> tags gekoppeld, dit kunnen immers verschillende straten zijn. De adres tags >> heb ik aan losse nodes gekoppeld met in tag "ref:bagid" het BAG id van de >> nummeraanduiding. >> >> ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te >> koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van het >> verblijfsobject in de tag "bag:vbo_id" en op de panden het BAG id van het >> pand in "bag:pand_id". >> >> rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met >> meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes. >> >> AssociatedStreet relaties >> ===================== >> AssociatedStreet relaties bieden veel voor en nadelen en het laatste >> woord is er nog niet over gesproken. Een voordeel dat in mijn ogen >> onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde >> straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen straten >> in OSM en straten uit andere bronnen. Dat gaat echter alleen werken >> associatedStreets gemeengoed zijn. Gezien de complexiteit bij het invoeren, >> zie ik dat nog niet zo snel gebeuren. >> De osmosis plug-in waarmee ik bezig ben bied een optie om >> associatedstreet relaties te genereren, inclusief BAG openbareruimte id. >> Vanwege de complexiteit bij het invoeren zijn we er echter vanaf gestapt om >> die te gebruiken. >> Ook ruudblank en rullzer lijken geen associatedstreet relaties toe te >> voegen. >> >> addr:city en addr:country tags >> ========================= >> Toevoegen van addr:city en addr:country tags aan adressen gaat bij het >> importeren van BAG data in een moeite mee. De vraag is of het wenselijk is >> om dat ook te doen. Het zorgt voor erg veel redundantie. >> ruudblank voegt addr:city toe, rullzer niet. >> Zelf heb ik het tot nu toe niet gedaan, maar ik neig er steeds meer naar >> om addr:city toch maar te gaan toevoegen. >> >> Huisnummers >> =========== >> De BAG bevat de kolommen huisnummer, huisletter en huisnummertoevoeging. >> OSM gebruikt alleen de tag "addr:housenumber". Hier is dus een vertaling >> nodig waarbij je kunt kiezen om wel of geen spaties tussen de verschillende >> delen van het huisnummer te plaatsen. >> De BAG laat gemeenten vrij in het gebruik van hoofd en kleine letters. >> >> rullzer: gebruikt geen spatie tussen huisnummer en huisletter >> (huisnummertoevoeging kom ik in zijn gebied niet tegen). >> ruudblank: gebruikt een spatie tussen huisnummer en huisletter en lijkt >> huisnummertoevoeging weg te laten. >> bagviewer.geodan.nl: gebruikt een spatie na het huisnummer en niet >> tussen huisletter en huisnummertoevoeging. >> http://www.kadaster.nl/BAG/producten/web.html: gebruikt geen spatie >> tussen huisnummer en huisletter, maar wel tussen huisletter en >> huisnummertoevoeging. >> >> Zelf gebruik ik de laatste conventie. Die is ook het beste leesbaar. >> (Vergelijk "42 abov" met "42a bov") >> >> De adressen in de BAG komen ook niet altijd overeen met die op de gevel, >> alleen al bij mij in de buurt: >> BAG: 19 BSA, gevel: 19 BIS A >> BAG: 100A A, gevel: 100 AA >> >> Versiebeheer >> =========== >> De BAG id code op zich is niet voldoende om te kunnen zien of een BAG >> object in OSM nog actueel is. Daarvoor heeft de BAG 2 extra velden: >> begindatumtijdvakgeldigheid en aanduidingrecordcorrectie. >> begindatumtijdvakgeldigheid bepaalt vanaf welk moment een object een >> bepaalde status heeft. Bijvoorbeeld 'Bouw gestart' (building:construction) >> of 'Pand in gebruik' (building:yes). Deze waarde kan als extra tag in OSM >> worden toegevoegd (Ik gebruik nu "bag:begindatum", met "yyyy-MM-dd >> hh:mm:ss" als datum formaat). >> aanduidingrecordcorrectie geeft aan dat er fouten gecorrigeerd zijn in de >> BAG data. Helaas krijgt het meest recente record niet de hoogste waarde >> voor 'aanduidingrecordcorrectie', maar de waarde 0. Het opslaan van deze >> waarde in een OSM tag heeft dus niet zo veel zin. Ik denk dat je de maximum >> waarde van 'aanduidingreccordcorrectie' in een OSM tag zou moeten zetten, >> maar omdat ik dit proces nog niet helemaal doorgrond, heb ik dat tot nu toe >> niet gedaan. Ook zou de betekenis van die tag zonder grondige documentatie >> alleen maar voor verwarring zorgen. Daarom heb ik er voorlopig voor gekozen >> om een tag "bag:extract" toe te voegen met daarin de naam van het zip >> bestand waaruit de BAG data afkomstig is. Daarmee is in ieder geval de >> versie van de BAG data af te leiden. >> >> Gertjan Idema >> >> >> _______________________________________________ >> Talk-nl mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-nl >> >> >
_______________________________________________ Talk-nl mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-nl
