2011/10/30 Robert Elsenaar :
> Dit voorstel houdt geen rekening met het niet aanwezig zijn van lokale
> kennis in veel gebieden waar jullie de import over heen sturen.
Die lokale kennis heb je toch echt nodig, elk voorstel dat dat niet
onderkent mist een essentieel onderdeel. En daarom is Stefans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 30-10-11 22:30, Robert Elsenaar schreef:
> Dit voorstel houdt geen rekening met het niet aanwezig zijn van
> lokale kennis in veel gebieden waar jullie de import over heen
> sturen.
Op gemeente grenzen na, sturen we nergens een import heen in dit
Dit voorstel houdt geen rekening met het niet aanwezig zijn van lokale kennis
in veel gebieden waar jullie de import over heen sturen.
Verder vind ik dat er weer te veel nadruk ligt op hoogwaardige kennis van
verschillende tools. Het wordt in mijn beleving weer een zelfde feestje als met
de 3ds
Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)
Martijn van Exel schreef:
De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die
gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers
hier, met soms veel tijd maar meestal maar een klein beetje. Mensen
k
2011/10/30 Stefan de Konink :
[...]
> Gebouwen;
> - Een (groepje) mapper(s) kan zich aanmelden voor een woonplaats
> - Dit groepje krijgt meldingen bij wijzigingen in de BAG database
> - Dit groepje kan zeggen: importeer de huizen uit de BAG database
> - Dit groepje kan zeggen: update de wijzi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
In de catacomben van IRC, is in geheim overleg een voorstel uit een
aantal toetsenborden gevloeid. Besmeurd met bloed van gestorven OSM
editors en licentie separatisten zodat deze tijdens Allerheiligennacht
hun torn van genade en vrees kunnen botvier
De bottleneck zit 'm in die 'medewerkers'. Wie gaat er door die
gegenereerde rapporten heenwerken? We zijn allemaal vrijwilligers
hier, met soms veel tijd maar meestal maar een klein beetje. Mensen
komen, en mensen gaan ook weer. Ik heb zelf honderden, misschien wel
duizenden building-objecten bewe
Op 30 oktober 2011 19:56 heeft Cartinus het
volgende geschreven:
> On Sunday 30 October 2011 19:26:09 Dick wrote:
>> Dan kunnen we, als de bag data is gewijzigd
>> de OSM data automatisch aanpassen.
>
> Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is
> simpel.
>
> Het probl
On Sunday 30 October 2011 19:26:09 Dick wrote:
> Dan kunnen we, als de bag data is gewijzigd
> de OSM data automatisch aanpassen.
Het probleem is helemaal niet het volgen van de BAG wijzigingen. Dat is
simpel.
Het probleem is het respecteren van andere edits op hetzelfde object. In de
BAG zit b
Dat is inderdaad heel kort door de bocht. Wat doe je met BAG-objecten
die sindsdien door anderen zijn aangepast? Automatisch is hier niet
triviaal.
De vraag is en blijft wat je te winnen hebt als OSM met het importeren
van een dataset die door derden al zo goed wordt bijgehouden. Mijn
antwoord blij
Heel kort door de bocht:
Als we nou alles wat we uit bag importeren voorzien van het bag object nummer en
versie (datum?) van de bag extract. Dan kunnen we, als de bag data is gewijzigd
de OSM data automatisch aanpassen.
3dShapes die niet aangepast zijn en overlappen met bag kunnen we gewoon
ver
Is mijn procedure niet overgekomen? Vanmorgen gaf ik al een idee over het
beschikbaar stellen van de laatste relevante BAG gegevens aan lokale mappers .
Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)
Henk Hoff schreef:
2011/10/30 Willem Sonke
Bij iedere update van de BA
2011/10/30 Willem Sonke
> Bij iedere update van de BAG moet wel gekeken worden of er door OSM'ers
> geen updates gedaan zijn. Bij een massale landelijke import en landelijke
> updates loop je het risico dat gegevens van mensen die zelf veel moeite
> hebben gedaan ze toe te voegen zomaar verwijder
On 30-10-11 12:58, Andre wrote:
De bestanden kunnen via 1 goedkoop abonnement van meen ik 160 euro
landelijk worden verkregen, waarom zou je dan niet landelijk
importeren? Per gemeente importeren vraagt om inconsistentie: de
actualiteit en verversingsfreqentie gaat dan per gebied afwijken en
daa
Gezien het feit dat de BAG data meta data bevat over de nauwkeurigheid, is
het niet zinvol deze te gebruiken?
De meeste gebouwen zijn ingemeten, dus dat zal beter zijn dan wat er nu in
OSM zit. Een klein percentage is niet ingemeten, ik vraag me af in hoeverre
daar in de huidige OSM data verbeteri
Ik zat zelf een beetje aan de volgende globale procedure te denken:
1) Zet de initiële brongegevens uit BAG om naar OSM formaat.
2) Open je gebied uit OSM in JOSM.
3) Leg hier overheen het zelfde gebiedje in OSM formaat dat uit de eerste
import gemaakt is.
4) Vergelijk deze twee lagen visueel waa
On 11-10-30 10:34 AM, Robert Elsenaar wrote:
Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze
voor het importeren laagdrempelige gemaakt moet worden, zodat veel
beetje ervaren lokale mappers het als een uitdaging zien om dit
vergelijk te maken.
Groet Robert
Met vriendelijk
Deze aanpak zie ik ook wel zitten. Ik denk echter dat de werkwijze voor het
importeren laagdrempelige gemaakt moet worden, zodat veel beetje ervaren lokale
mappers het als een uitdaging zien om dit vergelijk te maken.
Groet Robert
Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mob
On 29-10-11 21:31, Stefan de Konink wrote:
Het probleem is juist het overzetten. Als ObjectIDs stabiel zijn, dan
is er geen probleem. Maar juist een systeem dat dat stukje monitort en
intelligent is om fouten op te sporen en te herstellen... dat ontbreekt.
Als het nou om data ging die 1x per ja
On Sunday 30 October 2011 08:12:53 Frank Steggink wrote:
> On 11-10-30 12:52 AM, Stefan de Konink wrote:
> > Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
> > klap alle data laat importeren en daarmee het systeem laat bij houden
> > welke data is ingevoerd en welke data mapt na
On 11-10-30 12:52 AM, Stefan de Konink wrote:
Dat je geen object ids nodig hebt kan kloppen als het systeem in 1
klap alle data laat importeren en daarmee het systeem laat bij houden
welke data is ingevoerd en welke data mapt naar welk object.
Of je verplicht iedereen een apart importaccount aan
21 matches
Mail list logo
