On 07-11-16 11:45, joost schouppe wrote: > Om het aantal tags verder naar beneden te krijgen, zou > je source:geometry:entity en source:geometry:oidn gewoon samen kunnen > voegen, niet? Bijvoorbeeld: Gbg_3746049.
waarom ? met welk doel ? Waarom is een extra tag een probleem? Nu maak je het gewoon moeilijker om queries te draaien zoals: geef me alles van entity:GRB > Analyse kwaliteit GRB is spot on. > > Wat betreft verschil in kwaliteit tussen GRB en CRAB: > > - de adressen in CRAB zijn beter, aangezien daar het volledige datamodel > in zit (een notatie gekoppeld aan een locatie en aan gebouwen). Het GRB > krijgt slechts, met vertraging, de adresnotatie mee van de adressen waar > de adrespositie toevallig in ligt. Enkel CRAB kan dus overweg met één > adres dat bij meerdere gebouwen hoort, of één gebouw waar adressen in > verschillende straten bij horen. Klopt maar er staat veel crap in CRAB. Op de bruul in mechelen staan een nummer of 10 midden in de straat, wss wisten ze niet waar ze deze moesten parkeren. Dat heb je niet in GRB. Wat er in GRB zit is gewoon beter. Kwa compleetheid is CRAB wss wel vollediger. > > - de gebouwen in GRB en CRAB zijn in principe identiek. Wanneer er een > adres onstaat voor een nieuw gebouw, dan wordt er doorgaans een ruw > blokje ingetekend als huis. Dat geeft soms het idee van lage kwaliteit. > Maar als het GRB daar nog iets heeft, dan is dat per definitie > verouderd. Uiteindelijk wordt het gebouw ingemeten, en komt dan eerst in > GRB en dan in CRAB terecht. Daar kan mogelijk enige vertraging opzitten, > dus dan is GRB tijdelijk inderdaad beter. Het grote verschil is dit eigenlijk: crab adress data is niet gekoppeld aan een fysiek gebouw, die van GRB wel want er is maar 1 adress dat je kan zetten op een gebouw. Met crab kan je wel indelen in appartementnrs etc. Daar is de CRAB meerwaarde. In de import zijn alle gebouwen met dubbele adressen gedropped (de tags toch, niet het gebouw). vaak huizen op de hoek van 2 straten met 2 adressen maar met maar 1 gebouw, en in OSM kunnen we dat niet 2 addressen op 1 building. Dan werken we met entrance nodes. Daarom is de finishing touch eens GRB is geimporteerd om de CRAB tool te gebruiken om te vervolledigen op de hoeken. > > (misschien kan iemand van het AIV-AGIV hier nog enkele punten op de i > zetten) Yup, dat zou wel interessant zijn. > > Welke verschillen zie jij nog, Glenn? Het concept vooral, ik vind GRB meer bottom up approach en crab is meer top-down -do I make sense? Daarmee dat het GRB per gebouw 1 adress is voor OSM, we kunnen dat niet mappen met 2 adressen, de GRB database laat dit wel toe. Wij moeten een vertaalslag maken naar het OSM model. We kunnen simpelweg niet 2 addr:street tags maken voor 1 gebouw... We kunnen dit wel met addressed entrance nodes. Glenn > > 2016-11-07 11:29 GMT+01:00 Glenn Plas <[email protected] > <mailto:[email protected]>>: > > On 07-11-16 11:22, Glenn Plas wrote: > > (hence source:geometry:entity=GRB. > > Dju, dat moest zijn: > > source:geometry:entitity=Gbg of Knw, maar niet GRB. > > Glenn > > > _______________________________________________ > Talk-be mailing list > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/talk-be > <https://lists.openstreetmap.org/listinfo/talk-be> > > > > > -- > Joost @ > Openstreetmap > <http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter > <https://twitter.com/joostjakob> | LinkedIn > <https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup > <http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/> > > > _______________________________________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be > _______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
