Re: [OSM-talk-nl] Diverse vragen
1) Met zo'n mooie lijst zou ik de controle handmatig doen en wijzigen waar het daadwerkelijk letters moeten zijn. Ik weet van DenHaag dat veel van de straat namen WEL met cijfers worden geschreven. Groet ZMWandelaar -Oorspronkelijk bericht- From: Martijn van Exel Sent: Sunday, August 28, 2011 7:04 PM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] Diverse vragen 2011/8/28 Nico Witteman : Hallo allen, Ik ben nieuw in deze groep, met meteen maar een aantal vragen: 1. In Amsterdam zijn sommige straten genoteerd als “1e Helmersstraat”, enzovoorts, terwijl ze officieel “Eerste Helmersstraat” heten. Iemand bezwaar als ik dat corrigeer? En is daar dan een handige geautomatiseerde manier voor? Ik zou er niet van uit gaan dat de officiële benaming altijd 'Eerste' in plaats van '1e' is. Ik herinner me dat de rangtelwoorden op de straatnaamborden ook niet consequent voluit worden geschreven, als da tenminste enige indicatie is. Pas altijd op met automatische correcties. Er zijn vele manieren om dit te doen, maar evenzovele om het verkeerd te doen. Eén belangrijke misser maak je alvast niet, en dat is het doen zonder het eerst te overleggen. Maar er zijn meestal wel uitzonderingsgevallen waar je bij het maken van je script niet aan gedacht hebt. Oefen in elk geval eerst droog op een lokale dataset, doe dit soort acties met een afzonderlijke user en documenteer op de wiki. Ik heb een snelle check gedaan op het voorkomen van 1e/2e/3e/etc voor een ruime BBOX rond Amsterdam: namen in cijfers: 59 namen in letters: 84 Dit is het aantal unieke namen, niet het aantal objecten. Namen in cijfers: 1e Breeuwersstraat 1e Constantijn Huygensstraat 1e Glanshof 1e Guiswegdwarsstraat 1e Harenmakersdwarsstraat 1e Heidestraat 1e Helmersstraat 1e Hugo de Grootstraat 1e J C Mensinglaan 1e Jacob van Campenstraat 1e Jan Steenstraat 1e Jan van der Heijdenstraat 1e Kekerstraat 1e Kostverlorenkade 1e Loswal 1e Montessorischool 1e Nieuwstraat 1e Oosterparkstraat 1e Oosterstraat 1e Rijksbinnenhaven 1e Schinkelstraat 1e Sweelinckstraat 1e Weteringplantsoen 1e van der Helststraat 2e Breeuwersstraat 2e Coentunnel 2e Constantijn Huygensstraat 2e Glanshof 2e Helmersstraat 2e Hugo de Grootstraat 2e J C Mensinglaan 2e Jacob van Campenstraat 2e Jan Steenstraat 2e Jan van der Heijdenstraat 2e Katsloot 2e Kekerstraat 2e Kostverlorenkade 2e Leeghwaterstraat 2e Loswal 2e Montessori 2e Nieuwstraat 2e Oosterparkstraat 2e Oosterstraat 2e Rijksbinnenhaven 2e Schinkelstraat 2e Sweelinckstraat 2e Weteringplantsoen 2e van der Helststraat 3e Havenarm 3e Helmersstraat 3e Hugo de Grootstraat 3e Kekerstraat 3e Kostverlorenkade 3e Kruisstraat 3e Oosterparkstraat 3e Oosterstraat 3e Rijksbinnenhaven 3e Schinkelstraat Namen in letters: Derde Diem Derde Egelantiersdwarsstraat Derde Goudsbloemdwarsstraat Derde Leliedwarsstraat Derde Looiersdwarsstraat Derde Oosterparkstraat Derde Vogelstraat Derde Weteringdwarsstraat Derde Wittenburgerdwarsstraat Derde Zijweg Eerste Anjeliersdwarsstraat Eerste Atjehstraat Eerste Bloemdwarsstraat Eerste Boerhaavestraat Eerste Boomdwarsstraat Eerste Ceramstraat Eerste Christelijk Lyceum Eerste Coehoornstraat Eerste Diem Eerste Disteldwarsstraat Eerste Egelantiersdwarsstraat Eerste Emmastraat Eerste Goudsbloemdwarsstraat Eerste Hasselaerstraat Eerste Hoefweg Eerste Hogerwoerddwarsstraat Eerste Jan Steenstraat Eerste Jan van der Heijdenstraat Eerste Keucheniusstraat Eerste Laurierdwarsstraat Eerste Leeghwaterstraat Eerste Leliedwarsstraat Eerste Lindendwarsstraat Eerste Looiersdwarsstraat Eerste Marnixdwarsstraat Eerste Marnixplantsoen Eerste Nassaustraat Eerste Passeerdersdwarsstraat Eerste Ringdijkstraat Eerste Rozendwarsstraat Eerste Tuindwarsstraat Eerste Velddwarsweg Eerste Vogelstraat Eerste Weteringdwarsstraat Eerste Zijweg Eerste van Swindenstraat Tweede Anjeliersdwarsstraat Tweede Atjehstraat Tweede Bloemdwarsstraat Tweede Boerhaavestraat Tweede Boomdwarsstraat Tweede Ceramstraat Tweede Coehoornstraat Tweede Coentunnel Tweede Diem Tweede Disteldwarsstraat Tweede Egelantiersdwarsstraat Tweede Emmastraat Tweede Goudsbloemdwarsstraat Tweede Hasselaerstraat Tweede Hoefweg Tweede Hogerwoerddwarsstraat Tweede Keucheniusstraat Tweede Laurierdwarsstraat Tweede Leliedwarsstraat Tweede Lindendwarsstraat Tweede Looiersdwarsstraat Tweede Marnixdwarsstraat Tweede Marnixplantsoen Tweede Nassaustraat Tweede Oosterparkstraat Tweede Passeerdersdwarsstraat Tweede Rozendwarsstraat Tweede Tuindwarsstraat Tweede Velddwarsweg Tweede Vogelstraat Tweede Vooruitgangstraat Tweede Weteringdwarsstraat Tweede Wittenburgerdwarsstraat Tweede Zijweg Tweede van Swindenstraat Vierde Vogelstraat Vijfde Vogelstraat 2. Zijn er plannen om de huisnummers van BAG-viewer http://bagviewer.geodan.nl/index.html te gaan importeren? Zie het mailinglijst-archief, er zijn volgens mij geen concrete plannen om de BAG-huisnummers te importeren. Ik ben er geen voorstander van. Bij een import moet je ook nadenken over hoe d
Re: [OSM-talk-nl] Diverse vragen
Ervan uitgaan dat de spelling op de straatnaamborden de officiële spelling staat (je moet toch ergens van uitgaan ;-) klopt dit inderdaad voor de straten in Den Haag. Al hebben we niet zoveel "1e/2e" straten. Een 3e zou ik helemaal niet weten. Zie bijvoorbeeld deze StreetView beelden: http://maps.google.nl/?ll=52.073124,4.270779&spn=0.000857,0.002293&z=19&vpsrc=6&layer=c&cbll=52.073124,4.270779&panoid=Sr2yVWtSWzBG3OVPErQUzg&cbp=12,216.07,,1,-3.16 http://maps.google.nl/?ll=52.079241,4.301098&spn=0.000857,0.002293&z=19&vpsrc=6&layer=c&cbll=52.079241,4.301098&panoid=czW_yU3Kk0J8R-fn-lBpEA&cbp=12,20.39,,1,-2.68 En deze straten staan goed op OSM. Gegroet, Frank Op 29 augustus 2011 10:26 heeft Robert Elsenaar het volgende geschreven: > 1) Met zo'n mooie lijst zou ik de controle handmatig doen en wijzigen waar > het daadwerkelijk letters moeten zijn. Ik weet van DenHaag dat veel van de > straat namen WEL met cijfers worden geschreven. > > Groet > ZMWandelaar > > -Oorspronkelijk bericht- From: Martijn van Exel > Sent: Sunday, August 28, 2011 7:04 PM > To: OpenStreetMap NL discussion list > Subject: Re: [OSM-talk-nl] Diverse vragen > > 2011/8/28 Nico Witteman : >> >> Hallo allen, >> >> Ik ben nieuw in deze groep, met meteen maar een aantal vragen: >> >> >> >> 1. In Amsterdam zijn sommige straten genoteerd als “1e >> Helmersstraat”, enzovoorts, terwijl ze officieel “Eerste Helmersstraat” >> heten. Iemand bezwaar als ik dat corrigeer? En is daar dan een handige >> geautomatiseerde manier voor? > > Ik zou er niet van uit gaan dat de officiële benaming altijd 'Eerste' > in plaats van '1e' is. Ik herinner me dat de rangtelwoorden op de > straatnaamborden ook niet consequent voluit worden geschreven, als da > tenminste enige indicatie is. > > Pas altijd op met automatische correcties. Er zijn vele manieren om > dit te doen, maar evenzovele om het verkeerd te doen. Eén belangrijke > misser maak je alvast niet, en dat is het doen zonder het eerst te > overleggen. Maar er zijn meestal wel uitzonderingsgevallen waar je bij > het maken van je script niet aan gedacht hebt. Oefen in elk geval > eerst droog op een lokale dataset, doe dit soort acties met een > afzonderlijke user en documenteer op de wiki. > > Ik heb een snelle check gedaan op het voorkomen van 1e/2e/3e/etc voor > een ruime BBOX rond Amsterdam: > namen in cijfers: 59 > namen in letters: 84 > > Dit is het aantal unieke namen, niet het aantal objecten. > > Namen in cijfers: > 1e Breeuwersstraat > 1e Constantijn Huygensstraat > 1e Glanshof > 1e Guiswegdwarsstraat > 1e Harenmakersdwarsstraat > 1e Heidestraat > 1e Helmersstraat > 1e Hugo de Grootstraat > 1e J C Mensinglaan > 1e Jacob van Campenstraat > 1e Jan Steenstraat > 1e Jan van der Heijdenstraat > 1e Kekerstraat > 1e Kostverlorenkade > 1e Loswal > 1e Montessorischool > 1e Nieuwstraat > 1e Oosterparkstraat > 1e Oosterstraat > 1e Rijksbinnenhaven > 1e Schinkelstraat > 1e Sweelinckstraat > 1e Weteringplantsoen > 1e van der Helststraat > 2e Breeuwersstraat > 2e Coentunnel > 2e Constantijn Huygensstraat > 2e Glanshof > 2e Helmersstraat > 2e Hugo de Grootstraat > 2e J C Mensinglaan > 2e Jacob van Campenstraat > 2e Jan Steenstraat > 2e Jan van der Heijdenstraat > 2e Katsloot > 2e Kekerstraat > 2e Kostverlorenkade > 2e Leeghwaterstraat > 2e Loswal > 2e Montessori > 2e Nieuwstraat > 2e Oosterparkstraat > 2e Oosterstraat > 2e Rijksbinnenhaven > 2e Schinkelstraat > 2e Sweelinckstraat > 2e Weteringplantsoen > 2e van der Helststraat > 3e Havenarm > 3e Helmersstraat > 3e Hugo de Grootstraat > 3e Kekerstraat > 3e Kostverlorenkade > 3e Kruisstraat > 3e Oosterparkstraat > 3e Oosterstraat > 3e Rijksbinnenhaven > 3e Schinkelstraat > > > Namen in letters: > Derde Diem > Derde Egelantiersdwarsstraat > Derde Goudsbloemdwarsstraat > Derde Leliedwarsstraat > Derde Looiersdwarsstraat > Derde Oosterparkstraat > Derde Vogelstraat > Derde Weteringdwarsstraat > Derde Wittenburgerdwarsstraat > Derde Zijweg > Eerste Anjeliersdwarsstraat > Eerste Atjehstraat > Eerste Bloemdwarsstraat > Eerste Boerhaavestraat > Eerste Boomdwarsstraat > Eerste Ceramstraat > Eerste Christelijk Lyceum > Eerste Coehoornstraat > Eerste Diem > Eerste Disteldwarsstraat > Eerste Egelantiersdwarsstraat > Eerste Emmastraat > Eerste Goudsbloemdwarsstraat > Eerste Hasselaerstraat > Eerste Hoefweg > Eerste Hogerwoerddwarsstraat > Eerste Jan Steenstraat > Eerste Jan van der Heijdenstraat > Eerste Keucheniusstraat > Eerste Laurierdwarsstraat > Eerste Leeghwaterstraat > Eerste Leliedwarsstraat > Eerste Lindendwarsstraat > Eerste Looiersdwarsstraat > Eerste Marnixdwarsstraat > Eerste Marnixplantsoen > Eerste Nassaustraat > Eerste Passeerdersdwarsstraat > Eerste Ringdijkstraat > Eerste Rozendwarsstraat > Eerste Tuindwarsstraat > Eerste Velddwarsweg > Eerste Vogelstraat > Eerste Weteringdwarsstraat > Eerste Zijweg > Eerste van Swindenstraat > Tweede Anjeliersdwarsstraat > Tweede Atjehstraat > Tweede Bloemdwarsstraat > Tweede Boerhaavestraat > Tweede Boomdwar
Re: [OSM-talk-nl] Diverse vragen
Er zijn genoeg voorbeelden waar in dezelfde straat verschillende 'spellingen' voorkomen. Op zich zou ik het wel mooi vinden als de niet-officiele 'spelling' dan als alternatief wordt opgevoerd. Maakt zoeken waarschijnlijk makkelijker. Groet, Floris 2011/8/29 Frank Fesevur : > Ervan uitgaan dat de spelling op de straatnaamborden de officiële > spelling staat (je moet toch ergens van uitgaan ;-) klopt dit > inderdaad voor de straten in Den Haag. Al hebben we niet zoveel > "1e/2e" straten. Een 3e zou ik helemaal niet weten. > > Zie bijvoorbeeld deze StreetView beelden: > http://maps.google.nl/?ll=52.073124,4.270779&spn=0.000857,0.002293&z=19&vpsrc=6&layer=c&cbll=52.073124,4.270779&panoid=Sr2yVWtSWzBG3OVPErQUzg&cbp=12,216.07,,1,-3.16 > > http://maps.google.nl/?ll=52.079241,4.301098&spn=0.000857,0.002293&z=19&vpsrc=6&layer=c&cbll=52.079241,4.301098&panoid=czW_yU3Kk0J8R-fn-lBpEA&cbp=12,20.39,,1,-2.68 > > En deze straten staan goed op OSM. > > Gegroet, > Frank > > > Op 29 augustus 2011 10:26 heeft Robert Elsenaar > het volgende geschreven: >> 1) Met zo'n mooie lijst zou ik de controle handmatig doen en wijzigen waar >> het daadwerkelijk letters moeten zijn. Ik weet van DenHaag dat veel van de >> straat namen WEL met cijfers worden geschreven. >> >> Groet >> ZMWandelaar >> >> -Oorspronkelijk bericht- From: Martijn van Exel >> Sent: Sunday, August 28, 2011 7:04 PM >> To: OpenStreetMap NL discussion list >> Subject: Re: [OSM-talk-nl] Diverse vragen >> >> 2011/8/28 Nico Witteman : >>> >>> Hallo allen, >>> >>> Ik ben nieuw in deze groep, met meteen maar een aantal vragen: >>> >>> >>> >>> 1. In Amsterdam zijn sommige straten genoteerd als “1e >>> Helmersstraat”, enzovoorts, terwijl ze officieel “Eerste Helmersstraat” >>> heten. Iemand bezwaar als ik dat corrigeer? En is daar dan een handige >>> geautomatiseerde manier voor? >> >> Ik zou er niet van uit gaan dat de officiële benaming altijd 'Eerste' >> in plaats van '1e' is. Ik herinner me dat de rangtelwoorden op de >> straatnaamborden ook niet consequent voluit worden geschreven, als da >> tenminste enige indicatie is. >> >> Pas altijd op met automatische correcties. Er zijn vele manieren om >> dit te doen, maar evenzovele om het verkeerd te doen. Eén belangrijke >> misser maak je alvast niet, en dat is het doen zonder het eerst te >> overleggen. Maar er zijn meestal wel uitzonderingsgevallen waar je bij >> het maken van je script niet aan gedacht hebt. Oefen in elk geval >> eerst droog op een lokale dataset, doe dit soort acties met een >> afzonderlijke user en documenteer op de wiki. >> >> Ik heb een snelle check gedaan op het voorkomen van 1e/2e/3e/etc voor >> een ruime BBOX rond Amsterdam: >> namen in cijfers: 59 >> namen in letters: 84 >> >> Dit is het aantal unieke namen, niet het aantal objecten. >> >> Namen in cijfers: >> 1e Breeuwersstraat >> 1e Constantijn Huygensstraat >> 1e Glanshof >> 1e Guiswegdwarsstraat >> 1e Harenmakersdwarsstraat >> 1e Heidestraat >> 1e Helmersstraat >> 1e Hugo de Grootstraat >> 1e J C Mensinglaan >> 1e Jacob van Campenstraat >> 1e Jan Steenstraat >> 1e Jan van der Heijdenstraat >> 1e Kekerstraat >> 1e Kostverlorenkade >> 1e Loswal >> 1e Montessorischool >> 1e Nieuwstraat >> 1e Oosterparkstraat >> 1e Oosterstraat >> 1e Rijksbinnenhaven >> 1e Schinkelstraat >> 1e Sweelinckstraat >> 1e Weteringplantsoen >> 1e van der Helststraat >> 2e Breeuwersstraat >> 2e Coentunnel >> 2e Constantijn Huygensstraat >> 2e Glanshof >> 2e Helmersstraat >> 2e Hugo de Grootstraat >> 2e J C Mensinglaan >> 2e Jacob van Campenstraat >> 2e Jan Steenstraat >> 2e Jan van der Heijdenstraat >> 2e Katsloot >> 2e Kekerstraat >> 2e Kostverlorenkade >> 2e Leeghwaterstraat >> 2e Loswal >> 2e Montessori >> 2e Nieuwstraat >> 2e Oosterparkstraat >> 2e Oosterstraat >> 2e Rijksbinnenhaven >> 2e Schinkelstraat >> 2e Sweelinckstraat >> 2e Weteringplantsoen >> 2e van der Helststraat >> 3e Havenarm >> 3e Helmersstraat >> 3e Hugo de Grootstraat >> 3e Kekerstraat >> 3e Kostverlorenkade >> 3e Kruisstraat >> 3e Oosterparkstraat >> 3e Oosterstraat >> 3e Rijksbinnenhaven >> 3e Schinkelstraat >> >> >> Namen in letters: >> Derde Diem >> Derde Egelantiersdwarsstraat >> Derde Goudsbloemdwarsstraat >> Derde Leliedwarsstraat >> Derde Looiersdwarsstraat >> Derde Oosterparkstraat >> Derde Vogelstraat >> Derde Weteringdwarsstraat >> Derde Wittenburgerdwarsstraat >> Derde Zijweg >> Eerste Anjeliersdwarsstraat >> Eerste Atjehstraat >> Eerste Bloemdwarsstraat >> Eerste Boerhaavestraat >> Eerste Boomdwarsstraat >> Eerste Ceramstraat >> Eerste Christelijk Lyceum >> Eerste Coehoornstraat >> Eerste Diem >> Eerste Disteldwarsstraat >> Eerste Egelantiersdwarsstraat >> Eerste Emmastraat >> Eerste Goudsbloemdwarsstraat >> Eerste Hasselaerstraat >> Eerste Hoefweg >> Eerste Hogerwoerddwarsstraat >> Eerste Jan Steenstraat >> Eerste Jan van der Heijdenstraat >> Eerste Keucheniusstraat >> Eerste Laurierdwarsstraat >> Eerste Leeghwaterstraat >> Eerste Leliedwarsstraat >> Eerste Lindendwarsst
[OSM-talk-nl] Bouwjaar
Heren, Ik heb even zitten zoeken in de Wiki, maar kan geen tag vinden waarmee ik het bouwjaar van een gebouw aangeef. Weet iemand deze? groet Robert___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Bouwjaar
Staat wel iets over op de Wiki: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Building_attributes#Date_of_construction Gr, Floris 2011/8/29 Robert Elsenaar : > Heren, > Ik heb even zitten zoeken in de Wiki, maar kan geen tag vinden waarmee ik > het bouwjaar van een gebouw aangeef. > Weet iemand deze? > > groet > Robert > ___ > 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] Bouwjaar
Dank je, Voel me weer net een groentje. ;) groet Robert -Oorspronkelijk bericht- From: Floris Looijesteijn Sent: Monday, August 29, 2011 12:07 PM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] Bouwjaar Staat wel iets over op de Wiki: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Building_attributes#Date_of_construction Gr, Floris 2011/8/29 Robert Elsenaar : Heren, Ik heb even zitten zoeken in de Wiki, maar kan geen tag vinden waarmee ik het bouwjaar van een gebouw aangeef. Weet iemand deze? groet Robert ___ 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 --- Tekst ingevoegd door Panda GP 2011: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_9066&SPAM=true&path=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Diverse vragen
2011/8/29 Frank Fesevur: Ervan uitgaan dat de spelling op de straatnaamborden de officiële spelling staat (je moet toch ergens van uitgaan ;-) klopt dit inderdaad voor de straten in Den Haag. Al hebben we niet zoveel "1e/2e" straten. Een 3e zou ik helemaal niet weten. Daar zou ik niet zo van uit gaan. Nu is 1e en eerste wel een verschil, maar waar ik woon wordt burgemeester en pastoor op de straatnaambordjes meestal afgekort tot burg. en past. En dan zijn er dus minder snuggeren die die zeggen op de Burg Janssenring te wonen... Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Diverse vragen
Het gaat er ook om wat - en vooral voor wie - je wil mappen. Voor praktisch gebruik kan het handiger zijn om (ook) de schrijfwijze op de straatnaamborden te mappen. Bij gebrek aan een overzicht van de officiële namen (bevraag de gemeente!) zal je het hiermee - en met je eigen inzicht - moeten doen. Wat betreft 1e/eerste - ik denk dat deze namen niet dubbel getagd moeten worden, dit is typisch iets dat je aan de gebruikerskant (in de applicatie die de data gebruikt) moet afhandelen. Martijn 2011/8/29 Maarten Deen : > 2011/8/29 Frank Fesevur: >> >> Ervan uitgaan dat de spelling op de straatnaamborden de officiële >> spelling staat (je moet toch ergens van uitgaan ;-) klopt dit >> inderdaad voor de straten in Den Haag. Al hebben we niet zoveel >> "1e/2e" straten. Een 3e zou ik helemaal niet weten. > > Daar zou ik niet zo van uit gaan. Nu is 1e en eerste wel een verschil, maar > waar ik woon wordt burgemeester en pastoor op de straatnaambordjes meestal > afgekort tot burg. en past. En dan zijn er dus minder snuggeren die die > zeggen op de Burg Janssenring te wonen... > > Maarten > > ___ > Talk-nl mailing list > Talk-nl@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-nl > -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: > 2011/8/28 Nico Witteman : > >(...) > > > 2. Zijn er plannen om de huisnummers van BAG-viewer > > http://bagviewer.geodan.nl/index.html te gaan importeren? > > Zie het mailinglijst-archief, er zijn volgens mij geen concrete > plannen om de BAG-huisnummers te importeren. > Ik ben er geen voorstander van. Bij een import moet je ook nadenken > over hoe die geimporteerde data bij wordt gehouden; van de BAG komt > maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol > als je ook die mutaties opneemt. Maar hoe moet dat dan met > adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? > Dat zijn moeilijke vragen. > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets ondernomen op dit gebied? Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn het juist de regelmatige updates die deze informatie waardevoller maken dan 3dShapes. Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu al gruwelijk achterhaald. Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau. Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door de community aangebrachte wijzigingen zo respectvol mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een soort werkgroep opgezet moeten worden om deze uit te werken en een import zo soepel mogelijk te laten verlopen. Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk, maar dat zou het ministerie / de gemeentes definitief moeten kunnen beantwoorden. Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven, want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron doen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Er zijn voor en tegenstanders :) Ik ben zelf voorstander van zoveel mogelijk data in OpenStreetMap, als het tenminste nuttig is voor navigeren. En daar lijkt me in dit geval geen twijfel over mogelijk. Ik voer trouwens ook vrijwel geen huisnummers meer in tegenwoordig... Groet, Floris 2011/8/29 Oliver Heesakkers : > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> 2011/8/28 Nico Witteman : >> >(...) >> >> > 2. Zijn er plannen om de huisnummers van BAG-viewer >> > http://bagviewer.geodan.nl/index.html te gaan importeren? >> >> Zie het mailinglijst-archief, er zijn volgens mij geen concrete >> plannen om de BAG-huisnummers te importeren. >> Ik ben er geen voorstander van. Bij een import moet je ook nadenken >> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt >> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol >> als je ook die mutaties opneemt. Maar hoe moet dat dan met >> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? >> Dat zijn moeilijke vragen. >> > > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets > ondernomen op dit gebied? > > Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De > nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn > het juist de regelmatige updates die deze informatie waardevoller maken dan > 3dShapes. > Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu > al gruwelijk achterhaald. > > Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar > juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker, > namelijk plaatsbepaling op huisnummerniveau. > > Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates > aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door > de community aangebrachte wijzigingen zo respectvol mogelijk behandelen. > Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een > soort werkgroep opgezet moeten worden om deze uit te werken en een import zo > soepel mogelijk te laten verlopen. > Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk, > maar dat zou het ministerie / de gemeentes definitief moeten kunnen > beantwoorden. > > Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven, > want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron > doen. > > ___ > 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 (Was: Diverse vragen)
I2011/8/29 Oliver Heesakkers : > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> 2011/8/28 Nico Witteman : >> >(...) >> >> > 2. Zijn er plannen om de huisnummers van BAG-viewer >> > http://bagviewer.geodan.nl/index.html te gaan importeren? >> >> Zie het mailinglijst-archief, er zijn volgens mij geen concrete >> plannen om de BAG-huisnummers te importeren. >> Ik ben er geen voorstander van. Bij een import moet je ook nadenken >> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt >> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol >> als je ook die mutaties opneemt. Maar hoe moet dat dan met >> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? >> Dat zijn moeilijke vragen. >> > > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets > ondernomen op dit gebied? > > Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De > nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien zijn > het juist de regelmatige updates die deze informatie waardevoller maken dan > 3dShapes. > Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu > al gruwelijk achterhaald. > Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar > juist BAG-data voldoet aan een basis wens voor de moderne navigatie-gebruiker, > namelijk plaatsbepaling op huisnummerniveau. > > Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates > aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door > de community aangebrachte wijzigingen zo respectvol mogelijk behandelen. > Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een > soort werkgroep opgezet moeten worden om deze uit te werken en een import zo > soepel mogelijk te laten verlopen. > Ook bestaan er wellicht nog enkele vraagtekens omtrent het licentie-vraagstuk, > maar dat zou het ministerie / de gemeentes definitief moeten kunnen > beantwoorden. Het is niet alleen een kwestie van nut voor de eindgebruiker. Als iemand een navigatie-app wil maken of een website met een routeplanner, kan hij prima 'best of breed' datasets combineren. Dat betekent nog niet dat al die data in OSM hoeft te zitten. Bij een import moet je volgens mij op de eerste plaats uitgaan van het nut voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker. Die ken je immers niet - wat voor de ene groep gebruikers een heel nuttig thema is, is voor een andere categorie volstrekt irrelevant. Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld bijdragen aan een beter publiek gezicht van het project. De 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid daarvan kunt zetten (zie hieronder), heeft een mooiere kaart opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart, aantrekkelijker door geworden. 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit aangetoond, dat de AND-import en ook de TIGER-import hier in de VS daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit misschien ook -- dan vanuit een blanco vel. Weet iemand van een onderzoek dat dit argument ondersteunt of ontkracht? Naast deze criteria is volgens mij het 'data bij de bron'-argument heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij de organisatie die verantwoordelijk is voor de productie. Wat mij betreft is voor wat betreft de BAG-gegevens het laatste argument doorslaggevend: het betreft hier een landsdekkende, complexe databron met maandelijkse mutaties. Wat haal je je op de hals als je deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit van OpenStreetMap over een jaar of drie. Op de korte termijn is het een leuke winstpakker, maar op de lange termijn brengt het schade aan het project toe. > > Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven, > want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron > doen. We kunnen natuurlijk wel allerlei andere dingen met de BAG-gegevens doen. We kunnen tools maken die kijken waar we straten missen. We kunnen tools maken die ons erop attenderen dat er in een bepaald gebied veel nieuwe adressen zijn bijgekomen: tijd om er eens langs te gaan met een mapping party. -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] vraag van een leek
Hallo, Ik heb een navigatiesysteem gekocht in China. Het draait op windows ce 5.0. Via openstreetmap kwam ik een programma gosmore tegen. Wat ik wil doen is het volgende: Igo amigo verwijderen(heb dat al geprobeerd te updaten maar nogsteeds crasht het). Ik wil gosmore op de sd zetten en de exe hernoemen tot amigo.exe(volgens de instructies van de site mag dat). Maar... hoe kom ik aan een Nederlandse map? Bestaan die, en zo ja waar kan k een recente versie downloaden? Zijn er nederlandstalige audiofiles? En is de navigatie enigszins betrouwbaar? Groetenk, Dick Sterkenburg mobiel: 0684959329 email: d...@sterkenburg.us ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. groet, floris 2011/8/29 Martijn van Exel : > I2011/8/29 Oliver Heesakkers : >> Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >>> 2011/8/28 Nico Witteman : >>> >(...) >>> >>> > 2. Zijn er plannen om de huisnummers van BAG-viewer >>> > http://bagviewer.geodan.nl/index.html te gaan importeren? >>> >>> Zie het mailinglijst-archief, er zijn volgens mij geen concrete >>> plannen om de BAG-huisnummers te importeren. >>> Ik ben er geen voorstander van. Bij een import moet je ook nadenken >>> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt >>> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol >>> als je ook die mutaties opneemt. Maar hoe moet dat dan met >>> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? >>> Dat zijn moeilijke vragen. >>> >> >> Is er sinds die discussie / call to arms eind mei uberhaupt nog iets >> ondernomen op dit gebied? >> >> Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De >> nauwkeurigheid is veel groter en de informatie is uitgebreider. Bovendien >> zijn >> het juist de regelmatige updates die deze informatie waardevoller maken dan >> 3dShapes. >> Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die informatie nu >> al gruwelijk achterhaald. >> Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), maar >> juist BAG-data voldoet aan een basis wens voor de moderne >> navigatie-gebruiker, >> namelijk plaatsbepaling op huisnummerniveau. >> >> Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende updates >> aangepakt moeten worden, zodat we dubbel getekende gebouwen voorkomen en door >> de community aangebrachte wijzigingen zo respectvol mogelijk behandelen. >> Daarvoor zijn al enkele oplossingen aangedragen, maar er zal toch echt een >> soort werkgroep opgezet moeten worden om deze uit te werken en een import zo >> soepel mogelijk te laten verlopen. >> Ook bestaan er wellicht nog enkele vraagtekens omtrent het >> licentie-vraagstuk, >> maar dat zou het ministerie / de gemeentes definitief moeten kunnen >> beantwoorden. > > Het is niet alleen een kwestie van nut voor de eindgebruiker. Als > iemand een navigatie-app wil maken of een website met een > routeplanner, kan hij prima 'best of breed' datasets combineren. Dat > betekent nog niet dat al die data in OSM hoeft te zitten. Bij een > import moet je volgens mij op de eerste plaats uitgaan van het nut > voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker. > Die ken je immers niet - wat voor de ene groep gebruikers een heel > nuttig thema is, is voor een andere categorie volstrekt irrelevant. > > Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten > aflezen: > 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld > bijdragen aan een beter publiek gezicht van het project. De > 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid > daarvan kunt zetten (zie hieronder), heeft een mooiere kaart > opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart, > aantrekkelijker door geworden. > 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een > impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een > eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit > aangetoond, dat de AND-import en ook de TIGER-import hier in de VS > daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers > liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit > misschien ook -- dan vanuit een blanco vel. Weet iemand van een > onderzoek dat dit argument ondersteunt of ontkracht? > > Naast deze criteria is volgens mij het 'data bij de bron'-argument > heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij > de organisatie die verantwoordelijk is voor de productie. > > Wat mij betreft is voor wat betreft de BAG-gegevens het laatste > argument doorslaggevend: het betreft hier een landsdekkende, complexe > databron met maandelijkse mutaties. Wat haal je je op de hals als je > deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig > doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan > zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse > data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit > van OpenStreetMap over een jaar of drie. Op de korte termijn is het > een leuke winstpakker, maar op de lange termijn brengt het schade aan > het project toe. > >> >> Het is echter wel zaak om hiermee aan de gang te gaan en bezig te blijven, >> want het zou zonde zijn als we uiteindelijk helemaal niets met deze databron >> doen. > > We kunnen natuurlijk wel allerlei andere dingen met de BAG-gegevens > doen. We kunnen tools maken die kijken waar we straten missen. We > kunnen tools maken die ons erop attenderen dat er in een bepaald > ge
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
On 29-8-2011 23:44, Floris Looijesteijn wrote: ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, maar ook een vergelijking op geometrie kan. Je krijgt te maken met onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan weer af van wat er aangepast is: tags of vorm. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
ik zat er zelfs aan te denken om de bag-id - osm-id koppeling buiten de osm database te houden om vervuiling tegen te gaan. maar mogelijkheden genoeg... gr, floris 2011/8/29 Lennard : > On 29-8-2011 23:44, Floris Looijesteijn wrote: >> >> ik zie wel mogelijkheden voor een update script. >> ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. > > Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, > maar ook een vergelijking op geometrie kan. Je krijgt te maken met > onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan > weer af van wat er aangepast is: tags of vorm. > > -- > Lennard > > ___ > 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 (Was: Diverse vragen)
Op 29-08-11 22:42, Martijn van Exel schreef: Naast deze criteria is volgens mij het 'data bij de bron'-argument heel belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij de organisatie die verantwoordelijk is voor de productie. Wat mij betreft is voor wat betreft de BAG-gegevens het laatste argument doorslaggevend: het betreft hier een landsdekkende, complexe databron met maandelijkse mutaties. Wat haal je je op de hals als je deze data in OSM importeert? Je kunt dat bijna alleen maar éénmalig doen, wat betekent dat het merendeel van de BAG-data in OSM langzamaan zal verouderen, terwijl bij de bron (het Kadaster) elke maand frisse data te halen is. Bedenk je eens wat dat betekent voor de kwaliteit van OpenStreetMap over een jaar of drie. Op de korte termijn is het een leuke winstpakker, maar op de lange termijn brengt het schade aan het project toe. Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook? Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, gedetailleerder) dan 3dShapes? Hoe veel moeite is het om de data in te passen? Groeten, André ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel: > I2011/8/29 Oliver Heesakkers : > > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: > >> 2011/8/28 Nico Witteman : > >> >(...) > >> > > >> > 2. Zijn er plannen om de huisnummers van BAG-viewer > >> > http://bagviewer.geodan.nl/index.html te gaan importeren? > >> > >> Zie het mailinglijst-archief, er zijn volgens mij geen concrete > >> plannen om de BAG-huisnummers te importeren. > >> Ik ben er geen voorstander van. Bij een import moet je ook nadenken > >> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt > >> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol > >> als je ook die mutaties opneemt. Maar hoe moet dat dan met > >> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? > >> Dat zijn moeilijke vragen. > > > > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets > > ondernomen op dit gebied? > > > > Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De > > nauwkeurigheid is veel groter en de informatie is uitgebreider. > > Bovendien zijn het juist de regelmatige updates die deze informatie > > waardevoller maken dan 3dShapes. > > Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die > > informatie nu al gruwelijk achterhaald. > > Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), > > maar > > juist BAG-data voldoet aan een basis wens voor de moderne > > navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau. > > > > Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende > > updates aangepakt moeten worden, zodat we dubbel getekende gebouwen > > voorkomen en door de community aangebrachte wijzigingen zo respectvol > > mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen, > > maar er zal toch echt een soort werkgroep opgezet moeten worden om deze > > uit te werken en een import zo soepel mogelijk te laten verlopen. > > Ook bestaan er wellicht nog enkele vraagtekens omtrent het > > licentie-vraagstuk, maar dat zou het ministerie / de gemeentes > > definitief moeten kunnen beantwoorden. > > Het is niet alleen een kwestie van nut voor de eindgebruiker. Als > iemand een navigatie-app wil maken of een website met een > routeplanner, kan hij prima 'best of breed' datasets combineren. Dat > betekent nog niet dat al die data in OSM hoeft te zitten. Bij een > import moet je volgens mij op de eerste plaats uitgaan van het nut > voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker. > Die ken je immers niet - wat voor de ene groep gebruikers een heel > nuttig thema is, is voor een andere categorie volstrekt irrelevant. Key:addr is al een geaccepteerd onderdeel van de OSM-database en wordt in meerdere landen toegepast. Het is niet logisch om de Nederlandse huisnummers in een aparte database te gaan verstoppen terwijl de rest van de wereld zijn huisnummers wel gewoon in de OSM-database heeft zitten. Zelfs seamarks, stroomkabels en GSM-masten worden opgenomen in de database. Dat had van mij best in een aparte database gemogen omdat het geen recht doet aan de core functie van een streetmap, de BAG gegevens doen dat echter wel. > > Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten > aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld > bijdragen aan een beter publiek gezicht van het project. De > 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid > daarvan kunt zetten (zie hieronder), heeft een mooiere kaart > opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart, > aantrekkelijker door geworden. > 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een > impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een > eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit > aangetoond, dat de AND-import en ook de TIGER-import hier in de VS > daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers > liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit > misschien ook -- dan vanuit een blanco vel. Weet iemand van een > onderzoek dat dit argument ondersteunt of ontkracht? Ik denk juist dat een potentiele mapper bij een eerste blik op de website zal zien dat zijn gebied prima in elkaar zit en geen reden ziet een account te maken om aanpassingen te doen, maar zoals je zelf ook al zegt is dat nooit hard te maken. Tegelijkertijd is de mate waarin het product "af" is van belang voor het nut van OSM voor de eindgebruiker. Deur tot deur navigatie is tegenwoordig de standaard in navigatie. Er bestaat dus een spanningsveld tussen mensen het product OSM slijten en mensen actief aan het mappen krijgen. Na de AND en 3dShapes imports denk ik dat je je toch vooral op het eerste moet richten en daarbij kan een BAG-import een belangrijke rol spelen. > > Naast deze criteria is volgens mij het 'data bij de bron'-argument > heel belangrijk: dat
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 Lennard : > On 29-8-2011 23:44, Floris Looijesteijn wrote: >> >> ik zie wel mogelijkheden voor een update script. >> ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. > > Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, > maar ook een vergelijking op geometrie kan. Je krijgt te maken met > onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan > weer af van wat er aangepast is: tags of vorm. > Yep, een update-script kan, maar de crux is hoe je beslist welke updates voorrang genieten en welke criteria je daarvoor aanhoudt. Dat is heel lastig omdat de meetbare grootte van de aanpassing tussen twee BAG-versies niet evenredig hoeft te zijn met de 'waarde' ervan. Hoe wil je dat oplossen? -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 drek : > Op 29-08-11 22:42, Martijn van Exel schreef: >> >> Naast deze criteria is volgens mij het 'data bij de bron'-argument heel >> belangrijk: data voelt zich het beste thuis zo dicht mogelijk bij de >> organisatie die verantwoordelijk is voor de productie. Wat mij betreft is >> voor wat betreft de BAG-gegevens het laatste argument doorslaggevend: het >> betreft hier een landsdekkende, complexe databron met maandelijkse mutaties. >> Wat haal je je op de hals als je deze data in OSM importeert? Je kunt dat >> bijna alleen maar éénmalig doen, wat betekent dat het merendeel van de >> BAG-data in OSM langzamaan zal verouderen, terwijl bij de bron (het >> Kadaster) elke maand frisse data te halen is. Bedenk je eens wat dat >> betekent voor de kwaliteit van OpenStreetMap over een jaar of drie. Op de >> korte termijn is het een leuke winstpakker, maar op de lange termijn brengt >> het schade aan het project toe. > > Dit snap ik niet... BAG-data verouderen, maar dat doet 3dShapes toch ook? > Mijn vraag is dan ook: zijn BAG-data beter (nauwkeuriger, gedetailleerder) > dan 3dShapes? Hoe veel moeite is het om de data in te passen? Ja, BAG-data is beter (recenter, betere geometrie, veel meer atribuut-data). En inderdaad, het probleem met verouderende data treft 3DShapes eveneens. Kijk maar eens welk percentage van de 3DShapes-data nog nooit is aangeraakt sinds de import. Datzelfde geldt trouwens in mindere mate voor de AND-gegevens. De vraag is: beter (steeds) oude data dan géén data? Dat moet je je per dataset afvragen. -- martijn van exel schaaltreinen.nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
2011/8/29 Oliver Heesakkers : > Op maandag 29 augustus 2011 14:42:29 schreef Martijn van Exel: >> I2011/8/29 Oliver Heesakkers : >> > Op zondag 28 augustus 2011 11:04:42 schreef Martijn van Exel: >> >> 2011/8/28 Nico Witteman : >> >> >(...) >> >> > >> >> > 2. Zijn er plannen om de huisnummers van BAG-viewer >> >> > http://bagviewer.geodan.nl/index.html te gaan importeren? >> >> >> >> Zie het mailinglijst-archief, er zijn volgens mij geen concrete >> >> plannen om de BAG-huisnummers te importeren. >> >> Ik ben er geen voorstander van. Bij een import moet je ook nadenken >> >> over hoe die geimporteerde data bij wordt gehouden; van de BAG komt >> >> maandelijks een mutatiebestand uit, importeren in OSM is alleen zinvol >> >> als je ook die mutaties opneemt. Maar hoe moet dat dan met >> >> adresobjecten die ondertussen door een echt persoon zijn bijgewerkt? >> >> Dat zijn moeilijke vragen. >> > >> > Is er sinds die discussie / call to arms eind mei uberhaupt nog iets >> > ondernomen op dit gebied? >> > >> > Ik zie de BAG als zinnige vervanger voor de 3dShapes gebouwen. De >> > nauwkeurigheid is veel groter en de informatie is uitgebreider. >> > Bovendien zijn het juist de regelmatige updates die deze informatie >> > waardevoller maken dan 3dShapes. >> > Hoe mooi de 3dShapes ook zijn, op sommige (vele?) punten is die >> > informatie nu al gruwelijk achterhaald. >> > Sommige imports zijn zinvoller dan anderen (powerlines, datakabels), >> > maar >> > juist BAG-data voldoet aan een basis wens voor de moderne >> > navigatie-gebruiker, namelijk plaatsbepaling op huisnummerniveau. >> > >> > Er resteren nog vele vragen over hoe een BAG-import en daaropvolgende >> > updates aangepakt moeten worden, zodat we dubbel getekende gebouwen >> > voorkomen en door de community aangebrachte wijzigingen zo respectvol >> > mogelijk behandelen. Daarvoor zijn al enkele oplossingen aangedragen, >> > maar er zal toch echt een soort werkgroep opgezet moeten worden om deze >> > uit te werken en een import zo soepel mogelijk te laten verlopen. >> > Ook bestaan er wellicht nog enkele vraagtekens omtrent het >> > licentie-vraagstuk, maar dat zou het ministerie / de gemeentes >> > definitief moeten kunnen beantwoorden. >> >> Het is niet alleen een kwestie van nut voor de eindgebruiker. Als >> iemand een navigatie-app wil maken of een website met een >> routeplanner, kan hij prima 'best of breed' datasets combineren. Dat >> betekent nog niet dat al die data in OSM hoeft te zitten. Bij een >> import moet je volgens mij op de eerste plaats uitgaan van het nut >> voor OpenStreetMap en *niet* het mogelijke nut voor de eindgebruiker. >> Die ken je immers niet - wat voor de ene groep gebruikers een heel >> nuttig thema is, is voor een andere categorie volstrekt irrelevant. > > Key:addr is al een geaccepteerd onderdeel van de OSM-database en wordt in > meerdere landen toegepast. Het is niet logisch om de Nederlandse huisnummers > in een aparte database te gaan verstoppen terwijl de rest van de wereld zijn > huisnummers wel gewoon in de OSM-database heeft zitten. Zelfs seamarks, > stroomkabels en GSM-masten worden opgenomen in de database. Dat had van mij > best in een aparte database gemogen omdat het geen recht doet aan de core > functie van een streetmap, de BAG gegevens doen dat echter wel. Dat laat onverlet dat er verschillende manieren zijn om die adressen in de database te krijgen. Ik denk dat het importeren van BAG-gegevens alleen omdat 'het er is' en omdat er een standaard in OSM is om die adressen te coderen geen goed idee is. Die zee-elementen en GSM-masten zijn ook ooit geïmporteerd omdat de data 'er nu eenmaal was' en er een tag in OSM voor bestond. Iedereen heeft zijn eigen ideeën over wat er wel en wat er niet in OpenStreetMap thuishoort - de discussies daarover woeden bij mappen èn bij imports. Die discussie zou wat mij betreft niet leidend moeten zijn voor de beslissing al dan niet over te gaan tot een import. >> >> Het 'nut voor OpenStreetMap' kun je mijns inziens langs twee meetlatten >> aflezen: 1. Nut voor OpenStreetMap als project: een import kan bijvoorbeeld >> bijdragen aan een beter publiek gezicht van het project. De >> 3DShapes-import, hoeveel vraagtekens je ook bij de wenselijkheid >> daarvan kunt zetten (zie hieronder), heeft een mooiere kaart >> opgeleverd. OpenStreetMap is er als ondergrondlaag, als basiskaart, >> aantrekkelijker door geworden. >> 2. Nut voor de OpenStreetMap als gemeenschap: een import kan een >> impuls geven aan de lokale mappers-gemeenschap, door bijvoorbeeld een >> eerste aanzet te geven voor de kaart. Ik denk, maar dit is nooit >> aangetoond, dat de AND-import en ook de TIGER-import hier in de VS >> daaronder vallen. Mijn vermoeden is dat het merendeel van de mappers >> liever werkt vanuit een basiskaart -- hoe slecht van kwaliteit >> misschien ook -- dan vanuit een blanco vel. Weet iemand van een >> onderzoek dat dit argument ondersteunt of ontkracht? > > Ik denk juist dat een potentiele
