Re: [OSM-talk-nl] BAG viewer
Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Quoting Stefan de Konink ste...@konink.de: Op 02-11-11 21:02, Oliver Heesakkers schreef: OSM is echter veel laagdrempeliger. Onzin, als OSM laagdrempelig was kwamen er niet tal van mensen naar mij toe met de vraag hoe ze uberhaupt data uit OSM kunnen halen. Vector data ja, dat ze kunnen verwerken in met software. OSM XML != Standaard. Er staat laagdrempelig_er_. Ik zie ook niet een leek zomaar met GML data in de weer gaan. Geimporteerde BAG-data geeft de mapper gelegenheid om namen, ingangen, openingstijden, etc. toe te voegen en geeft die mapper ook makkelijk de gelegenheid om de plaatsing van wegen te orienteren aan de gebouwen. Een GML bestand geeft diezelfde functionaliteit. Ik mis het punt. Omdat die tags niet in IMGeo (het uitwisselingsformaat voor BAG) gedefinieerd staan? De huisnummers (en binnenkort wellicht postcodes) die BAG levert zijn relevante en goed bruikbare data die ook juist voor afgeleide (navigatie)producten juist heel interessant zijn. Het bij elkaar houden van de data voorkomt dan licentievraagstukken en compatibiliteitsproblemen. Het introduceert alleen maar licentie vraagstukken. De vraag: waarom BAG data geedit door OSM'ers opeens niet meer PD zijn bijvoorbeeld. De OSM-licentie blijft gelden (be it CC-BY-SA 2.0 of ODbL). Alles wat in OSM zit, voldoet hieraan. Er is geen enkel bezwaar om PD data te importeren. Afgeleide data hoeft, per definitie, niet PD te blijven. De originele bron blijft dat natuurlijk wel. Anders zou daar een share-alike clausule aanhangen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 08:40, Frank Steggink schreef: Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Zover ik heb begrepen kan er bij iedere bronhouder worden gerapporteerd als er dingen in de BAG niet kloppen. Databankenrecht waarop? BAG licentie gelezen? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yguUACgkQYH1+F2Rqwn0k2gCghHZFOpkzda0yWp0krAaKuFe1 Ez8An3nEC2rgdIrFZFJeVvyaHES98dpZ =DA39 -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
Quoting Stefan de Konink ste...@konink.de: Op 03-11-11 08:40, Frank Steggink schreef: Stefan, Oliver heeft het over het importeren van BAG-data in OSM, niet om toevoegingen van OSM-gebruikers weer aan de BAG te voeden. Dit kan ook helemeal niet. De BAG wordt bijgehouden door de bronhouders; de gemeenten. Wat authentieke BAG-data is, wordt door deze bronhouders bepaald. Er is geen mogelijkheid om OSM op de een of andere manier op de Landelijke Voorziening aan te sluiten, om de BAG van extra attributen te voorzien. Wij kunnen alleen besluiten om BAG-data uit de LV te onttrekken en deze in OSM te importeren. (Wat dit betreft heb ik wel twijfels over het databankenrecht, maar dat is een andere discussie.) Zover ik heb begrepen kan er bij iedere bronhouder worden gerapporteerd als er dingen in de BAG niet kloppen. Succes als je deze weg wilt bewandelen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 14:19, Frank Steggink schreef: Succes als je deze weg wilt bewandelen :) Je kunt maar beter de eerste zijn he :) Terugmelden onjuistheden BAG Antwoord Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het onderwerpveld van de e-mail dient u de gemeente waarbinnen het object valt te vermelden. Dat lijkt me nu een perfect e-mail adres om automatisch verbetering naar toe te sturen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Mag ik de BAG-data aan derden verstrekken? Antwoord De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd is om overheden efficiënter en klantgerichter te laten werken, is de BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de Rijksoverheid is immers dat overheidsinformatie op een makkelijke en goedkope wijze ter beschikking moet worden gesteld aan iedereen die daar behoefte aan heeft. In beginsel is er aan hergebruik van deze informatie geen belemmering gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet voor commerciële doeleinden worden gebruikt. De overheid heeft deze afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari 2012. Daarna mag, ook de postcode uit de BAG voor commerciële doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG. Is de FUD nu eigenlijk over? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB /YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC =j4/p -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG viewer
On 11-11-03 05:13 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 14:19, Frank Steggink schreef: Succes als je deze weg wilt bewandelen :) Je kunt maar beter de eerste zijn he :) Terugmelden onjuistheden BAG Antwoord Als u gerede twijfel heeft over de juistheid van de informatie in de BAG, dan kunt u dit per email melden bij b...@kadaster.nl. In het onderwerpveld van de e-mail dient u de gemeente waarbinnen het object valt te vermelden. Dat lijkt me nu een perfect e-mail adres om automatisch verbetering naar toe te sturen :) Databankenrecht waarop? BAG licentie gelezen? Niet recent, dus het is me ontgaan. Google brengt me wel op deze site uit: http://wiki.openstreetmap.org/wiki/BAG . Jeroen's samenvatting waar naar verwezen wordt laat het databankenrecht nog als open punt (onverlet het auteursrecht). Mag ik de BAG-data aan derden verstrekken? Antwoord De BAG is er voor iedereen! Hoewel de BAG in eerste instantie gebouwd is om overheden efficiënter en klantgerichter te laten werken, is de BAG ook beschikbaar voor burgers en bedrijven. Het beleid van de Rijksoverheid is immers dat overheidsinformatie op een makkelijke en goedkope wijze ter beschikking moet worden gesteld aan iedereen die daar behoefte aan heeft. In beginsel is er aan hergebruik van deze informatie geen belemmering gekoppeld. Een uitzondering hierop vormt de postcode. Vanwege een oude afspraak tussen de overheid en PostNL mag de postcode uit de BAG niet voor commerciële doeleinden worden gebruikt. De overheid heeft deze afspraak opgezegd en deze belemmering vervalt uiterlijk 1 februari 2012. Daarna mag, ook de postcode uit de BAG voor commerciële doeleinden worden gebruikt, net zoals alle andere gegevens uit de BAG. Is de FUD nu eigenlijk over? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6yvYwACgkQYH1+F2Rqwn1riACfXX9f/IsJBLwOw59yeTpuqcqB /YoAn2EoPtB3ncEss3W6PiOAG0KtNXYC =j4/p -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Volgens Google is de zin Mag ik de BAG-data aan derden verstrekken? en het antwoord inderdaad op de Kadaster-site te vinden (. Goed nieuws dus ;) Alleen jammer dat hun site het net lijkt te hebben begeven, omdat ik een foutmelding krijg. Het zou beter zijn als het Kadaster dit op een zodanige plek neerzet dat het statement niet door een ASP.NET fout onbereikbaar wordt. Ik had dit antwoord nog niet gezien, omdat ik OSM minder intensief volg, maar toch de BAG-discussie interessant vind. Ik wilde geen FUD zaaien, maar had zelf nog last van een restant 'D'. Je weet dat ik pro-open data ben, maar ik heb geen tijd en zin om achteraf met juridische zaken geconfronteerd te worden bij overhaaste beslissingen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
Stefan vroeg mij in een PM om wat meer van mijn idee te ontsluiten. Helaas is die niet in de hele groep terecht gekomen. Hier dan alsnog. Ik hoop hiermee een waardevolle bijdrage te leveren. Hier een korte functionele beschrijving: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in OSM gebracht. Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update bevat alleen de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus voor ieder blok verschillende hoeveelheden blok-updates aanwezig zijn. Een Delta Uitlevering BAG (DUB) van een blok heeft de volgende kenmerken: - De uitlevering wordt gemaakt op het moment van aanvraag - De uitlevering bevat de geaggregeerde BAG gegevens vanaf Laatste Update Datum (LUD) (Voor de eerste uitlevering van ieder blok (init) is deze datum bv 01-01-2011) - Bestand heeft een unieke code. - Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan worden. Activiteiten DUB site: De DUB site is een site waarin de ingelogde OSM gebruiker op de kaart van OSM 1 blok kan aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site aggregeert alle blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en een unieke code worden in een database opgeslagen. De site controleert automatisch of de unieke code van een uitstaande DUB voorkomt in de omschrijving van de changesets. Komt deze voor dan wordt het record van de DUB verwijderd en krijgt het blok een LUD die gelijk is aan de uitgifte datum van de net verwijderde DUB. De geldigheid van een uitlevering kan gesteld worden op 1 maand. Heeft de aanvrager zijn aanvraag niet omgezet in een valide changeset, dan kan via een mail het systeem hem hiertoe aansporen dit alsnog te doen. (Eventueel kan voor voorkomende gevallen een mogelijkheid geschapen worden om de DUB zonder changeset vrij te geven zonder de aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt wel verwijderd, maar de LUD niet aangepast. Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB uitstaat, dan kan deze geweigerd worden en verwezen worden naar de betrokken gebruiker. Onderling kan een oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?) De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM gegevens en brengt op deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload hij de gegevens en vernoemd in de omschrijving van de changeset de unieke code uit de DUB. Voordelen: - BAG data inclusief updates kunnen gecontroleerd in OSM worden ingebracht. - Lokale gebruikers bepalen de update frequentie - Mappers worden optimaal geholpen in het beschikbaar krijgen van de meest relevante BAG gegevens voor een geografisch blok. - Mappers hebben niet meer technisch kennis nodig dan JOSM technieken/vaardigheden. - Er is een maximaal overzicht over de BAG status per geografisch blok. Nadelen: - De initiële update is een arbeidsintensief werk. De updates zullen relatief eenvoudig zijn. - Niet ieder blok in OSM zal voorzien zijn met OSM data. Ik hoop met het bovenstaande duidelijk te hebben gemaakt hoe ik een mogelijkheid zie om de BAG data beschikbaar te stellen aan de mappers-crowd. mvrgr Robert Elsenaar -Oorspronkelijk bericht- From: Stefan de Konink Sent: Wednesday, November 02, 2011 11:22 PM To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Semi automatisch BAG voorstel -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 02-11-11 21:02, Oliver Heesakkers schreef: Een complete postGIS-database? Ik kan me voorstellen dat dat een flinke jongen moet zijn voor de hele BAG, zeker als die machine ook een (mapnik-)render moet maken en serveren. Wat zou er niet 'beschikbaar zijn' aan een voor mapnik geschikte PostGIS database op mijndev. Ik voel aan je eerste reactie al weer dat je er compleet vijandig in staat. Halloween was je zeker compleet ontschoten. Wie gaat dit dan (belangeloos) doen/opzetten? Hoeveel tijd is hiermee wel niet gemoeid? Dezelfde mensen die hier belangeloos in de afgelopen jaren met OpenStreetMap hebben gewerkt? Betaal jij mijn uurtjes als ik je vertel hoelang ik daar mee bezig ben? Ik begrijp ook dat deze database niet beschikbaar zal zijn voor de gemiddelde mapper, hetgeen niet erg open is voor een _open_streetmap. De database van OpenStreetMap.org is in zijn
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
Hoi Robert, Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan. On 11-11-03 08:59 PM, Robert Elsenaar wrote: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, omdat de spreiding in omvang veel minder divers is dan bij gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo opknippen. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in OSM gebracht. Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update bevat alleen de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus voor ieder blok verschillende hoeveelheden blok-updates aanwezig zijn. Een Delta Uitlevering BAG (DUB) van een blok heeft de volgende kenmerken: - De uitlevering wordt gemaakt op het moment van aanvraag - De uitlevering bevat de geaggregeerde BAG gegevens vanaf Laatste Update Datum (LUD) (Voor de eerste uitlevering van ieder blok (init) is deze datum bv 01-01-2011) - Bestand heeft een unieke code. - Bestand is in .OSM formaat zodat deze direct in JOSM geladen kan worden. Delta's (was-wordt) lijken leuk, maar zijn dat absoluut niet. Het werkt alleen voor nieuwe toevoegingen, die niet in OSM zitten. Met updates en verwijderingen moet gebruik worden gemaakt van de bestaande way-/relation-ID's in OSM én het juiste versienummer. Daarbij komt nog dat je in een OSM bestand (ik neem aan dat je dan de JOSM smaak bedoelt) niet ziet wat er verwijderd is. Ook houdt deze benadering geen rekening met wijzigingen die gebruikers aan bestaande data hebben toegevoegd. Als het ID en versienummer zou kloppen, dan moeten wijzigingen alle gebruikers-tags toevoegen. Dit gaat in theorie alleen werken als het proces dat de DUB-bestanden maakt gebruik maakt van up-to-date OSM data én als de gebruiker zsm de wijzigingen gaat posten. Dit neemt nog steeds niet het bezwaar weg dat dit semi-geautomatiseerd is. Aangezien je werkzaam bent in de ICT, weet je ook dat software niet altijd 100% klopt ;) Changesets kúnnen gerevert worden, maar dat moet zeker geen gewoonte worden! Activiteiten DUB site: De DUB site is een site waarin de ingelogde OSM gebruiker op de kaart van OSM 1 blok kan aangeven en vervolgens daarvan een DUB kan bestellen. De DUB site aggregeert alle blok-updates vanaf de LUD. De gebruikersnaam, de aanvraag datum en een unieke code worden in een database opgeslagen. De site controleert automatisch of de unieke code van een uitstaande DUB voorkomt in de omschrijving van de changesets. Komt deze voor dan wordt het record van de DUB verwijderd en krijgt het blok een LUD die gelijk is aan de uitgifte datum van de net verwijderde DUB. De geldigheid van een uitlevering kan gesteld worden op 1 maand. Heeft de aanvrager zijn aanvraag niet omgezet in een valide changeset, dan kan via een mail het systeem hem hiertoe aansporen dit alsnog te doen. (Eventueel kan voor voorkomende gevallen een mogelijkheid geschapen worden om de DUB zonder changeset vrij te geven zonder de aanpassingen door te hebben gevoerd in OSM. Het DUB record wordt wel verwijderd, maar de LUD niet aangepast. Wordt een aanvraag gedaan voor een blok waarvan reeds een DUB uitstaat, dan kan deze geweigerd worden en verwezen worden naar de betrokken gebruiker. Onderling kan een oplossing voor dit oponthoud gevonden worden. (Vrijgeven van het blok?) Ik vind dit teveel klinken als een technische oplossing (unieke ID's, locking, geldigheidsperiodes), i.p.v. een oplossing die gaat werken. De DUB-site is een veel te bazig systeem. Ook in dit verhaal blijf ik missen hoe je met gewijzigde en verwijderde features om denkt te gaan. De gebruiker vergelijkt na ontvangst de DUB.OSM met de huidige OSM gegevens en brengt op deze laatste de wijzigingen aan. Is de gebruiker klaar dan upload hij de gegevens en vernoemd in de omschrijving van de changeset de
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6zCZQACgkQYH1+F2Rqwn344ACeL7b7uXctFO6i5DpUDREMO7MS vcIAn2UTqRn/LcE8tfVYW0BeoThhWWQE =9l7U -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Fwd: Re: Semi automatisch BAG voorstel
Hoi Robert, On 11-11-03 10:21 PM, rob...@elsenaar.info wrote: Ik voel me allerminst opgejaagd wilt. Je 'alternatief' zie ik meer als een zinvolle aanvulling op mijn idee dan een discriminerend alternatief. Mijn feedback is inderdaad bedoeld als aanvulling. Ik kan me trouwens indenken dat je je niet opgejaagd voelt, aangezien jacht op zondag(middag) (en tussen zonsondergang en -opgang) niet toegestaan is. Positieve punten: - Opdelen in anders soortige 'blokken' stuit bij mij op geen bezwaar, Ik gaf al aan dat die opdeling voor mijn idee niet relevant is. Voor de uiteindelijke uitwerking natuurlijk wel. en dat gaf je juist aan. - De een DUB opgedeeld wordt in drie bestanden (INS, CHG, DEL) is een uitstekende toevoeging. Leuk wellicht als je ook voor deze vormen kunt kiezen. Uit de door jou gekozen benaming valt af te leiden dat je uit het 8.3 tijdperk stamt ;) Wat mij betreft is mijn alternatief geen keuze t.o.v. jouw voorstel, vanwege de eerder genoemde redenen. - Hoe je de changeset laat corresponderen met de DUB's is mij gelijk. Mij leek een unieke ID, gegenereerd door de website zelf een beter idee. Dat dit uiteindelijk niet via de changeset, maar via een handmatige terugkoppeling, dat vind ik niet zo belangrijk. Het laatste zorgt er welvoor dat de gebruiker een verwerking kan uitvoeren door meer CS te up[loaden. Maar goed. Een handmatige stap, tevens als controle, is een goede aanvulling in een proces dat redelijk foutgevoelig is. Ook bij het handmatig verwerken van mutaties kunnen fouten optreden. Aan meerdere changesets per upload had ik nog niet eens gedacht. Dus afvinkmogelijkheid erbij. Voor mutaties verwacht ik niet dat dit nodig zal zijn, maar wel voor de initiële upload. - Je laat de basis van mijn idee volledig overeind: Ik vind het belangrijk als BAG data op eenvoudige manier beschikbaar komt voor de grote massa en in een vorm waarbij de verwerking niet meer vaardigheden vraagt dan bij het normale mappen voor gevorderden. Het zinvol opdelen van dit werk is altijd een goed idee. Over de invulling kan men twisten ;) Grote massa vind ik hier overdreven, maar dat dit breder gedragen moet worden dan door een driekoppig groen monster is een feit ;) Ik hoop dat daadwerkelijk dat dit idee bij de groep wordt omarmt en gerealiseerd wordt. Helaas heb ik te weinig technische kennis om in die fase mijn bijdrage te leveren :-( De uitwerking omvat meer dan het inrichten van de omgeving en het schrijven van code. Testen en documentatie zijn minstens net zo belangrijk, zeker om meer, maar tevens minder ervaren gebruikers erbij te betrekken (alhoewel een bepaalde mate van vaardigheid met JOSM vereist is). Dit proces is en blijft redelijk gecompliceerd. Het is niet eenvoudiger te maken dan een bepaald niveau. Enige discipline blijft dus nodig. Goede documentatie ondersteunt daarin. Ik wil jou dit werk niet aansmeren, maar mensen ervan bewust maken dat het niet bij programmeren alleen ophoudt. Frank groet Robert Citeren Frank Stegginkstegg...@steggink.org: Hoi Robert, Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan. On 11-11-03 08:59 PM, Robert Elsenaar wrote: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, omdat de spreiding in omvang veel minder divers is dan bij gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo opknippen. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG is in het begin immers nog niet op dat blok in OSM gebracht. Deze blok-update wordt de 'init-update' genoemd. Iedere volgende blok-update bevat alleen de wijzigingen uit een betreffende maand. Op een zeker moment kunnen er dus voor ieder blok verschillende hoeveelheden blok-updates aanwezig zijn. Een Delta Uitlevering BAG (DUB) van een blok heeft de volgende kenmerken: - De uitlevering wordt gemaakt op het moment van aanvraag - De
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Ik neem aan dat dit in de metadata af te leiden is. NEN3610-objecten (dus ook BAG-objecten, want het IMGeo-model is op NEN3610 gebaseerd) hebben een vaststaand ID, dus de datum van laatste wijziging, of puur het feit dat een object in het BAG-mutatiebestand voorkomt (afhankelijk van de te kiezen levering) zegt genoeg. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 22:52, Frank Steggink schreef: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Oke, maar hoe weet je dan of die objecten al in OSM staan? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6zEFoACgkQYH1+F2Rqwn30SACgksM4qZcq6M8fguHE78GlRxmn f4EAnR1jz/2HBsMQRiXGRqJadgkUYrEx =MVgL -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?
On 11-11-03 10:52 PM, Frank Steggink wrote: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Ik neem aan dat dit in de metadata af te leiden is. NEN3610-objecten (dus ook BAG-objecten, want het IMGeo-model is op NEN3610 gebaseerd) hebben een vaststaand ID, dus de datum van laatste wijziging, of puur het feit dat een object in het BAG-mutatiebestand voorkomt (afhankelijk van de te kiezen levering) zegt genoeg. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Ik zat net nog te denken aan de BasisRegistratie Topografie (BRT) die per 1 januari a.s. gratis wordt. Dit is dus inclusief Top10NL, de dataset waar het PBL de 3dShapes dataset uit heeft afgeleid. Mits de BRT onder een gunstige licentie beschikbaar komt en mits de 3dShapes data zonder al te veel poespas is op te waarderen, dan zouden we hetzelfde proces kunnen gebruiken om de landuse data bij te werken (en andere Top10NL objecten toe te voegen, zoals kleine waterlopen, muren, etc.). De verversingscyclus zal veel onregelmatiger zijn dan bij de BAG, alhoewel ik niet weet wat de huidige situatie is. (Er geldt wel een soortgelijke terugmeldplicht als voor de BAG, dus het zou kunnen zijn dat updates veel continuer zijn.) Met het opwaarderen van 3dShapes bedoel ik het volgende: * actualiseren data (3dShapes is door de bank genomen 6 jaar oud) * gebouwen worden niet meegenomen, want daar hebben we de BAG voor * bijwerken / update van tags, om zo de ongelukkige categorisering van 3dShapes te niet te doen (combinatie bos en heide - natuur), en zelfs gebruik maken van meer specifieke tagging (bijv. loof-/naaldbos). De randvoorwaarden zijn als volgt: * de geometrie moet niet al te veel afwijken, anders zouden we net zo goed overnieuw kunnen beginnen, maar met de opgedane ervaring raad ik dat niemand aan. * de hoeveelheid werk moet in eerste instantie behapbaar zijn om de actualiseringsslag te doen. Zomaar een ideetje op de late avond ;) Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fwd: Re: Semi automatisch BAG voorstel
Dat er naast codering ook een hoop documentatie nodig is klopt. Binnen dat domein wil ik mijn kennis en vaardigheden graag inzetten. Ik zie een testing and documenting weekend wel zitten. Wellicht dat ik dáár wel een gelegenheid voor heb. Dat onhandige zien dat wel tegen die tijd Robert Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Frank Steggink stegg...@steggink.org schreef: Hoi Robert, On 11-11-03 10:21 PM, rob...@elsenaar.info wrote: Ik voel me allerminst opgejaagd wilt. Je 'alternatief' zie ik meer als een zinvolle aanvulling op mijn idee dan een discriminerend alternatief. Mijn feedback is inderdaad bedoeld als aanvulling. Ik kan me trouwens indenken dat je je niet opgejaagd voelt, aangezien jacht op zondag(middag) (en tussen zonsondergang en -opgang) niet toegestaan is. Positieve punten: - Opdelen in anders soortige 'blokken' stuit bij mij op geen bezwaar, Ik gaf al aan dat die opdeling voor mijn idee niet relevant is. Voor de uiteindelijke uitwerking natuurlijk wel. en dat gaf je juist aan. - De een DUB opgedeeld wordt in drie bestanden (INS, CHG, DEL) is een uitstekende toevoeging. Leuk wellicht als je ook voor deze vormen kunt kiezen. Uit de door jou gekozen benaming valt af te leiden dat je uit het 8.3 tijdperk stamt ;) Wat mij betreft is mijn alternatief geen keuze t.o.v. jouw voorstel, vanwege de eerder genoemde redenen. - Hoe je de changeset laat corresponderen met de DUB's is mij gelijk. Mij leek een unieke ID, gegenereerd door de website zelf een beter idee. Dat dit uiteindelijk niet via de changeset, maar via een handmatige terugkoppeling, dat vind ik niet zo belangrijk. Het laatste zorgt er welvoor dat de gebruiker een verwerking kan uitvoeren door meer CS te up[loaden. Maar goed. Een handmatige stap, tevens als controle, is een goede aanvulling in een proces dat redelijk foutgevoelig is. Ook bij het handmatig verwerken van mutaties kunnen fouten optreden. Aan meerdere changesets per upload had ik nog niet eens gedacht. Dus afvinkmogelijkheid erbij. Voor mutaties verwacht ik niet dat dit nodig zal zijn, maar wel voor de initiële upload. - Je laat de basis van mijn idee volledig overeind: Ik vind het belangrijk als BAG data op eenvoudige manier beschikbaar komt voor de grote massa en in een vorm waarbij de verwerking niet meer vaardigheden vraagt dan bij het normale mappen voor gevorderden. Het zinvol opdelen van dit werk is altijd een goed idee. Over de invulling kan men twisten ;) Grote massa vind ik hier overdreven, maar dat dit breder gedragen moet worden dan door een driekoppig groen monster is een feit ;) Ik hoop dat daadwerkelijk dat dit idee bij de groep wordt omarmt en gerealiseerd wordt. Helaas heb ik te weinig technische kennis om in die fase mijn bijdrage te leveren :-( De uitwerking omvat meer dan het inrichten van de omgeving en het schrijven van code. Testen en documentatie zijn minstens net zo belangrijk, zeker om meer, maar tevens minder ervaren gebruikers erbij te betrekken (alhoewel een bepaalde mate van vaardigheid met JOSM vereist is). Dit proces is en blijft redelijk gecompliceerd. Het is niet eenvoudiger te maken dan een bepaald niveau. Enige discipline blijft dus nodig. Goede documentatie ondersteunt daarin. Ik wil jou dit werk niet aansmeren, maar mensen ervan bewust maken dat het niet bij programmeren alleen ophoudt. Frank groet Robert Citeren Frank Stegginkstegg...@steggink.org: Hoi Robert, Aangezien het jachtseizoen voor de meeste soorten wild op 15 oktober is geopend, begin ik met schieten ;) Uiteraard draag ik zelf ook wat wild aan. On 11-11-03 08:59 PM, Robert Elsenaar wrote: Nederland is opgedeelt in blokken (bv 5 bij 5 km) of in gemeentegrenzen. Dit is niet relevant voor het idee. Dit is wel degelijk relevant. Een 5x5 km grid is een willekeurige onderverdeling in Nederland. Je krijgt dan ook te maken met een zeer ongelijke verdeling van de werklast. Vergelijk een blok van 5x5 hartje Amsterdam met een willekeurige stek op de Veluwe. Aangezien opdeling in gemeenten ook een ongelijke verdeling maakt, wil ik hierbij pleiten voor een onderverdeling in 4-cijferige postcodegebieden. Dit is behapbaar, omdat de spreiding in omvang veel minder divers is dan bij gemeenten, laat staan een willekeurig grid. De postcodes zelf kunnen weliswaar nog niet gebruikt worden, maar we kunnen de data wel zo opknippen. Voor elk van deze 'blokken' kan de gebruiker een aanvraag doen van klaarstaande wijzigingen in de BAG data. Het moedersysteem heeft al enige zaken voorbereid voor de aanvraag gedaan kan worden. - Het moeder systeem heeft alle updates van BAG opgesplitst in 'blok-updates'. Merk op dat voor ieder blok niet voor iedere maand een update is. Bij geen wijziging ontstaat er voor dat blok geen blok-update. Merk ook op dat ieder blok in het begin altijd 1 blok-update heeft en dat deze alle BAG data uit dat blok bevat. BAG
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
On 11-11-03 11:06 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 22:52, Frank Steggink schreef: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Oke, maar hoe weet je dan of die objecten al in OSM staan? Zoals gezegd wordt alleen naar de BAG-data zelf gekeken en niet naar OSM om de drie changeset-bestanden te maken. De data danwel historie bevat alle benodigde informatie. De verantwoordelijkheid voor de initiële vulling, verwijdering van (redundant geworden) 3dShapes gebouwen, overzetten van tags, etc. ligt bij de lokale gebruiker. Hij is uiteindelijk de scheidsrechter die bepaalt welke BAG-objecten in OSM terechtkomen en hoe dat gebeurt. Het in te richten proces is ervoor bedoeld om hem te ondersteunen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Semi automatisch BAG voorstel
Frank. Ik had het niet beter kunnen zeggen. Je moet maar denken dat ook fysieke observaties niet 100% in OSM terecht komen. Wellicht dat we besluiten om ook wanneer een DUB reeds is afgemeld, deze door een ander opnieuw opvraagbaar is . Ik kan niet zien wat dáár de gevolgen van zijn. Ik kan me in sommige gevallen dáár wel het nut van inzien. Met vriendelijke groeten, Robert Elsenaar (Verzonden vanaf Mobile) Frank Steggink stegg...@steggink.org schreef: On 11-11-03 11:06 PM, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 22:52, Frank Steggink schreef: On 11-11-03 10:37 PM, Stefan de Konink wrote: Ik vind Franks postcode idee nog beter dan mijn woonplaats idee. Maar ik heb wel een aantal bezwaren bij het 'nieuw' en 'gewijzigd'. Wanneer is iets nieuw? Als het nog niet is geimporteerd? Is iedere wijziging dan 'nieuw'? Voor de bepaling van wat nieuw en wat gewijzigd is, wordt alleen naar de BAG-data zelf gekeken. De initiële levering is per definitie nieuw. Ook BAG-objecten die zijn ontstaan tussen de begin- en einddatum zijn nieuw. Gewijzigd is een BAG-object dat al eerder bestond, maar waarvan de eigenschappen (geometrie of attributen) gewijzigd zijn tussen de begin- en einddatum. Oke, maar hoe weet je dan of die objecten al in OSM staan? Zoals gezegd wordt alleen naar de BAG-data zelf gekeken en niet naar OSM om de drie changeset-bestanden te maken. De data danwel historie bevat alle benodigde informatie. De verantwoordelijkheid voor de initiële vulling, verwijdering van (redundant geworden) 3dShapes gebouwen, overzetten van tags, etc. ligt bij de lokale gebruiker. Hij is uiteindelijk de scheidsrechter die bepaalt welke BAG-objecten in OSM terechtkomen en hoe dat gebeurt. Het in te richten proces is ervoor bedoeld om hem te ondersteunen. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG-update: ook bruikbaar voor BRT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 03-11-11 23:08, Frank Steggink schreef: Zomaar een ideetje op de late avond ;) Gegeven dat al die data PD is waarom zou je in vredesnaam meerdere databronnen gaan mergen? In plaats van kijken hoeveel PD data nu naar buiten komt, daar een nieuwe gecombineerde dataset van maken, en daar een best of both worlds van maken? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk6zGvoACgkQYH1+F2Rqwn1DNwCeIZ8ggL6/71wIaM9SmiCVJp+P orAAnRMgTah+949vWPHFL+4MFbzLwhPP =UmZe -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
