On 07-11-16 12:12, joost schouppe wrote: > > > > > 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:* > > > Dus beter datum geometrie + oidn, niet uidn. (+ type eenheid)
die uidn zat er eerst zelfs niet in, de datum vond ik veel interessanter om te vermijden dat mensen toch geomtrie gaan aanpassen op basis van oudere sat foto's. En dat is ondertussen al gebeurd btw met het beetje dat is geimporteerd ondertussen. Ik vind het beter hoe het nu staat (evidently) en ik bekijk dit vanuit een programmer/sysadmin standpunt ook. Ik weet uit ervaring dat dit beetje extra taggin werkt gewoon ons later zoveel hoofdpijn gaat besparen. > > Die tag uiteen trekken als data is iets dat enkel voor onderhoud nodig > gaat zijn - dus iets complex wordt nog net iets complexer. Lijkt mij > niet zo'n groot probleem. > > > > > 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/ > <http://grbtiles.byteless.net/docs/> > > > Dat is niet wat Ben bedoelt. Hij heeft het op de wilde imports, of > mensen die overtekenen uit het GRB zonder respect voor wat er al stond. > Dat lijkt mij trouwens het beste argument voor een grote import: als we > het niet doen met jouw excellente tool, dan gaan mensen het toch doen, > alleen veel slechter. Ha, idd, ik heb die ook al gezien, dan heb je dus enkel geomtries aangepast, in lokeren geloof ik dat er zo'n geval is, iemand heeft daar los GRB data geimporteerd, zonder onderverdeling in gebouwen/tags etc. zonder die source tags kan je hier niets mee, zelfs ik nu niet, tenzij ik spatial queries ga bouwen en dan nog is het lastig als iemand ondertussen een gebouw heeft aangepast. > > > > 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. > > > Ik heb ook altijd begrepen dat de uitdaging bij importeren up to date > houden is. Als daar technologische middelen voor zijn, dan moeten we die > toch gebruiken. Ik snap net als jij niet wat de meerwaarde is van de GRB > gebouwen ENKEL als OSM objecten te gaan updaten. Ideaal toch als we > zowel the crowd als het AIV (AGIV) kunnen gebruiken? Vandaar die source tags! en natuurlijk is het super dan de crab tool complementair bleek te zijn na analyse/code. > 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 ? > > > It's politics baby, niet te veel energie aan verspillen. Dus, we vragen gewoon meer, we includen alle source tags en als er een issue is dan moeten ze de data zelf bekijken en zullen ze vaststellen dat dit de MVP is ( minimum viable product ) Als hostage kunnen we uidn dan afgeven als we de datum bewaren. Maar eerlijk gezegd, ik snap de vragen omtrent die tags volledig, maar zeggen zonder de data te bekijken dat het niet echt nodig is is iets te snel door de bocht, ik verwacht van de OSM upstream organisatie onderbouwde argumenten die ik dan snel technisch kan weerleggen, maar emotie en/of politics heeft hier maar weinig ruimte en begrip bij mij als de technologische oplossing minderwaardig blijkt te zijn. Ik wou dat Sander ook even zijn 2c. hier kwam bijsteken :) Glenn > > > _______________________________________________ > 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
