Ik zou dat vooral zo blijven doen. Kleinschalig, maar beetje bij beetje geraken de gebouwen er dan toch accuraat in.
Jo Op 7 november 2016 12:52 schreef Marc Gemis <marc.ge...@gmail.com>: > wat ik vooral jammer vind is dat het allemaal redelijk lang aansleept. > (ik wijs naar niemand) > Het is gewoon niet leuk om nu nog manueel gebouwen te gaan tekenen als > je weet dat die toch gaan vervangen worden door betere examplaren. > En je hebt die gebouwen nu eenmaal nodig om erfgoed tags of andere > zaken te mappen. Je kan dan niet gewoon maar een puntje zetten. > > Dus ja, ik gebruik Glenn's tool nu al om die gebouwen te tekenen die > ik nodig heb. Gemakkelijker en beter dan wat ik zelf zou tekenen. > We mogen GRB toch als achtergrond gebruiken, niet ? > > m > > > 2016-11-07 12:44 GMT+01:00 Ben Abelshausen <ben.abelshau...@gmail.com>: > > Het is duidelijk dat dit, vanuit technologie standpunt de beste oplossing > > is, dat is niet waar het probleem zit. Dit is zeker een elegante > oplossing. > > Het punt is dat we die wiki pagina moeten maken en er moet community > > consensus zijn (min-of-meer) over de aanpak en ik geloof niet dat we dat > op > > deze manier gaan bereiken. > > > > Het is 100% zeker dat dit zever gaat geven met de import lijst en data > > working group en ik heb gewoon geen goesting om mij daar weer mee bezig > te > > houden. En ik bedoel inderdaad mensen die op eigen houtje GRB gebouwen > over > > de bestaande hebben gezet... dat moeten we vermijden. > > > > Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen > éénmalig > > te importeren en dan verder te onderhouden op de gangbare manier. Dit > gaat > > de weg van de minste pijn zijn, eenvoudig te implementeren en geen (of > > minder) zever met de data working group of de import lijst. > > > > In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die > tags > > allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te > > verdedigingen op de import lijst. > > > > Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel > > deze discussie via mail te voeren... > > > > @marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook > > logischer omdat enkel de data die in die changeset nieuw is ook die bron > > heeft. > > > > Met vriendelijke groeten, > > Best regards, > > > > Ben Abelshausen > > > > Met vriendelijke groeten, > > Best regards, > > > > Ben Abelshausen > > > > 2016-11-07 12:14 GMT+01:00 Marc Gemis <marc.ge...@gmail.com>: > >> > >> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te > >> combineren met data die je op een andere manier hebt gevonden (bv. via > >> survey of wikipedia). > >> source:geometry of iets dergelijks ok, maar niet source aub. > >> > >> m. > >> > >> 2016-11-07 12:02 GMT+01:00 Glenn Plas <gl...@byte-consult.be>: > >> > On 07-11-16 11:51, Ben Abelshausen wrote: > >> >> Glenn, > >> >> > >> >> Kijkend naar de BAG import wat denk je van dit: > >> >> > >> >> source = GRB > >> >> ref:grb = 3746049-6379775 (oidn-uidn) > >> > > >> > Dat gaat een leuke query worden in de database, met regular > expressions > >> > en stuff. pfff. En die uidn is volgens mij nog van een minder belang > >> > dat de datum. Die is leesbaar voor eindgebruikers, die uidn versie > >> > nummer zegt echt niks. > >> > > >> > Ik ben trouwens niet akkoord met die ref tag. het is geen ref, het is > >> > een source ref. daarom source:* > >> > > >> >> Die datum is niet echt relevant voor mappers en als ik het goed > begrijp > >> >> kunnen we dit via bovenstaande ref nog altijd uit de originele data > >> >> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen > >> >> gebruiken om andere tags te genereren omdat daar toch wel > verschillende > >> >> zaken inzitten precies. > >> > > >> > Dat gebeurd nu ook, maar er is ook overlapping tussen entities. > >> >> > >> >> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is > >> >> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van > mappers > >> >> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar > >> >> mijn > >> >> menig een slechte zaak is. > >> > > >> > Nee, dan heb je niet opgelet ;-) !!! wij deleten niets. De history > van > >> > een gebouw wordt bewaard. je moet de plugin gebruiken om geometries > te > >> > migreren. zie docs : http://grbtiles.byteless.net/docs/ > >> > > >> >> > >> >> Eens de import klaar is en we hebben alle gebouwen doen we > maintenance > >> >> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. > We > >> >> kunnen nog altijd de datasets vergelijken om te bekijken waar de > >> >> wijzigingen zitten. > >> > > >> > Die maintenance is nu simpel: match entity en oidn en je weet exact > >> > welk gebouw je hebt. > >> > > >> > Welk probleem zijn we nu eigenlijk aan het oplossen met die tags. Ik > >> > versta niet wat het grote probleem is en waarom we het ons moeilijker > >> > moeten maken ook als het makkelijk kan ? > >> > > >> > Die meta data is voor automatisatie te faciliteren, niet zomaar dus. > >> > > >> > Glenn > >> > > >> > > >> >> > >> >> Met vriendelijke groeten, > >> >> Best regards, > >> >> > >> >> Ben Abelshausen > >> >> > >> >> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas <gl...@byte-consult.be > >> >> <mailto:gl...@byte-consult.be>> wrote: > >> >> > >> >> 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 > >> >> Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org> > >> >> https://lists.openstreetmap.org/listinfo/talk-be > >> >> <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
