> > Ja eens we de hackday gepland hebben hoopte ik om dit af te werken... ik > heb wel mijn bedenkingen bij die id's die we meenemen, niet ik > persoonlijk maar de import-list gaat hier wel problemen van maken. Zijn > er al bestaande voorbeelden waarbij het zo gegaan is?
Tuurlijk, vb BAG import nederland heeft ook referenties. Het gaat over terugkoppelbaarheid naar GRB. Anders is het enige dat je doet een copy/paste https://wiki.openstreetmap.org/wiki/NL:BAG https://wiki.openstreetmap.org/wiki/BAGimport nu de Nederlanders hebben volgens mij een verkeerde tag gekozen, nml in de 'ref' namespace . de source: namespace is veel geschikter. Dat is het verschil momenteel met BAG De waarde van de import ligt net in die tags. En wat er is is echt minimum omwille van de aard van de data. de source tags zijn allemaal nodig want GRB heeft nog een heel leuk feit dat die enkel unieke ID's heeft voor gebouwen per entity (Gba,Gbg,Knw etc ...) Dus als je die combineert kan je niet anders dan voor elk gebouw aangeven vanwaar die komt (hence source:geometry:entity=GRB. De tool gebruikt die ook. het gaat eigenlijk over een 4-tal tags, waarvan er eventueel 1tje kan gedropped worden, maar het maakt het gemakkelijk: je hebt bv: source:geometry:entity = Gbg source:geometry:date = 2013-01-08 source:geometry:oidn = 3746049 source:geometry:uidn = 6379775 source=GRB https://www.agiv.be/producten/grb/objectcatalogus/entiteiten Verklaring: - entity, laag.... - datum van laatste aanpassing , verbouw je of komt de landmeter nog eens langs dan zal deze aangepast worden, samen met de uidn - oidn = object ID - uidn = versie (deze zou je kunnen droppen en rekenen op source:geomtry:date bij vergelijken van datasets indien GRB geupdate wordt) source=GRB (verplichte OSM tag voor deze dingen) Om eerlijk te zijn, als iemand die source references zomaar afschiet weet hij echt niet waarover hij praat en kan hij onmogelijk oordelen over de import. Het is echt andersom, je mag mij eens proberen te overtuigen dat een import zonder backreferences naar de source beter is dan 1tje met. Dit is zoals de afzender niet zetten op de enveloppe van een brief maar wel verwachten als deze niet te bestellen is dat je die zo terugkrijgt. Niet dus... als je niet weet vanwaar hij komt. Ik zie ook de issue niet direct met wat extra text data. In tijden van 2TB harddisks voor 80 euro zeker niet.... De kwestie over kwaliteit copy/paste ik graag Sanders zijn entry uit de wikipage: Quality of GRB data - https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB GRB building data has two quality levels: measured and drawn from aerial imagery. "The measured data is always very precise (more precise than anything we can achieve), but may be outdated a few months. The data derived from aerial imagery is about as good as we can achieve in OSM with mapping from correctly aligned pictures. In general, everything that can be measured from public roads is also measured. So the front sides of the buildings are measured, the back sides aren't. Dat is exact de nagel op de kop. Naar mijn ervaring door met die data bijna een jaar te spelen kan ik wel 1 ding zeggen: GRB kwaliteit is volgens mij veel hoger dan AGIV/CRAB." Echt veel beter dan OSM vaak. (aangezien veel mensen het dak mappen en niet de basis van een gebouw) Dus al bij al, ik denk dat we nu gewoon zo een wikipagina nodig hebben zoals de Nederlanders het gedaan hebben : https://wiki.openstreetmap.org/wiki/BAGimport En we tikken alles een voor een af. Ik migreer de code van de testtool naar de fancy versie ervan waardoor niemand begint te zagen over te grote knoppen (probeer maar eens 1000 keer per dag een knopje van 4 pixels te klikken als je pogrammeert) die excellent zijn als je ontwikkelt en dan kunnen MAC users met kleine schermpjes er ook aan uit want momenteel is er echt zero eye-candy aanwezig. Alle efforts is gestoken in de data handling. Glenn > > Met vriendelijke groeten, > Best regards, > > Ben Abelshausen > > > _______________________________________________ > 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
