Bedankt Ligfietser. We zijn al sinds november of december vorig jaar bezig met die reeks, dus als je dat soort artikels graag leest, neem dan eens een kijkje op http://osm.be onder de kop “Blog”. Er zijn nog wel interessante mensen aan de beurt geweest.
Stevebeer leuk idee ;), begin eens met de oldies, als newbie heb ik denk ik niet zo veel te melden. Maar ja of die zich vrijwillig melden ?
Nou, newbie is een ruim begrip. 
Mapper sinds: 12 april 2012
Mijn interesses zijn:
Ik zit te wachten wat RWS ons te bieden heeft, en de mogelijkheden hiervan.
-
Nieuwbouw projecten in kaart brengen
-
Wegen hieromtrent mappen via Mapillary en verder in kaart brengen, evt met hulp van het Nwb.
-
Wandelpaden/mtb routes in kaart brengen, als deze nog niet bestaan in OSM
-
POI’s aanbrengen
-
Voorpret ivm vakantie, hierbij omgeving verkennen via OSM, en later in kaart brengen. Denk hierbij hoofdzakelijk aan touristische zaken in de ruime zin des woords.
-
Vandalisten in de gaten houden, hierbij bedoel ik niet dat iemand iets aanpast op een “betere” manier maar echt vandalisme, zoals een fly-over of een by-pass op een (kleine) rotonde etc. meestal hebben deze personen helaas maar 1 mutatie op haar naam staan.
Beste Commodoortje, voor mijn gevoel klopt dat, ik kom iedere keer weer tot de ontdekking dat ik 100 methodes/hoeken/mogelijkheden ken en vervolgens dat ik de volgende 100 niet ken, das dus gevoel. Of de bekende redenering hoe meer ik weet des te meer inzicht ik krijg dat er nog veel meer is dat ik niet weet, ouderwets misschien.
Mijn projecten; Nieuwe Hollandse Waterlinie; Grebbelinie, kortom Linies (40 stuks); Voetpaden; verhardingen; Infrastructuur, bruggen, tunnels en sluizen; Verlichting; Bouwwerken en materialen; Historische vliegvelden uit vervlogen tijden (40-45) en voor alles geldt buiten verkenbaar en gezien. Buitenwerk is leuker dan binnenwerk maar levert een veelvoud aan werk op.
Mappilairy; HOT bijeenkomsten; Maar ook het volgen van Newbies voor advies en vragen naar het waarom; Polders en watergangen.
Op dit moment ben ik niet met een speciaal project bezig.
De afgelopen jaren heb ik vooral de knooppuntenroutes (wandelen) in Noord Limburg/aansluitend deel van Noord Brabant bezig geweest.
Bij het invoeren van de routes heb ik tevens de kaart aangepast voor de topografische aspecten (landuse, beken, hekjes) m.b.v. Bing en wat ik met wandelen zag.
Tevens zijn alles bospaden in mij directe omgeving ingevoerd.
De RWS data lijkt mij ook wel iets, maar ook data van bv. het waterschap (de loop van alle beken) zou erg zinvol zijn.
De gemeente 's-Hertogenbosch geeft jaarlijks nieuwe luchtfoto’s vrij. Ik zat hier al enige tijd naar uit te kijken en deze week was het het eindelijk weer zo ver. Dus mijn project van deze week is proberen te herinneren wat er allemaal veranderd is het afgelopen jaar.
Enige tijd geleden ontdekte ik dat sinds maart alle Nederlandse straten in wikidata staan. ik ben voorzichtig begonnen dit toe te voegen aan straten in mijn omgeving, zie: http://overpass-turbo.eu/s/dkV
Mij lijkt dit een nuttige toevoeging voor beide projecten en bovendien is de data makkelijk te onderhouden. Enig probleem is dat het invoeren nogal veel werk is. Ik ben hier inmiddels een paar uur mee bezig en ik denk niet dat ik veel meer tijd ga wijden aan het systematisch invoeren van wikidata tags. Ik zal mij in de toekomst waarschijnlijk beperken tot straten die ik om andere redenen toch al bewerk.
om het opzoeken van de wikidata tag iets sneller te maken heb ik de volgende code toegevoegd aan ‘tag2link_sources.xml’ van de Tag2Link plugin:
<!-- zoek op wikidata -->
<src name="Wikidata">
<rule>
<condition k="name" />
<link name="zoek straat op wikidata" href="http://www.wikidata.org/w/index.php?search=straat+in+'s-hertogenbosch+%v%" />
</rule>
</src>
Verwijder of vervang het “straat+in+'s-hertogenbosch+” gedeelte als je dit buiten den bosch wilt gebruiken. dit staat er in voor het geval je een dorpsstraat zoekt oid.
Volledige automatisering lijkt me niet de juiste manier, maar als er ideeën zijn om dit iets minder handmatig te maken dan hoor ik dat graag.
Interessant! weer wat geleerd!
Automatiseren zou wel kunnen denk ik; je zou alle highway=X met name=Y die in dezelfde gemeente voorkomen kunnen matchen.
Is er ook een relatie om aan te geven dat alle segmenten van een bepaalde weg (alsmede alle adresnodes aan die weg) bij die straat horen?
Hoewel ik hiervan een zeer laag fout percentage verwacht zal dit zeker fouten opleveren. De vraag is echter hoeveel fouten acceptabel zijn. En of minder fouten maken dan handmatig werken goed genoeg is, want in mijn beleving is de osm community vergefelijker voor menselijke fouten dan geautomatiseerde.
Maar als iemand hier een (semi) automatisch proces van kan maken juich ik dit toe.
Er is de associatedStreet relatie, maar hiervan zijn de voordelen gering en het heeft wel alle nadelen van de complexiteit van relaties.
Interessante informatie die ik misschien ook kan gebruiken voor de BAG plugin. Wel vreemd dat er geen label (naam) aan de wikidata hangt.
Ik heb wel een aandachtspuntje: Wikidata gebruikt zo te zien de officiële BAG straatnamen. Deze komen niet altijd overeen met de OSM straatnamen. In OSM worden straatnamen zo veel mogelijk voluit geschreven. In jouw voorbeeld gebiedje kwam ik de “Mgr. Zwijsenstraat” tegen. Volgens de OSM conventies zou dit de Monseigneur Zwijsenstraat moeten zijn. Het wordt daarmee in eerste instantie iets lastiger om straatnamen te vergelijken, maar daar kunnen we straks wikidata voor gebruiken.
Een tijdje geleden heb ik al eens een lijst samengesteld van straatnamen die verschillen tussen BAG en OSM. Die zouden we misschien kunnen gebruiken om de wikidata straat ids in OSM te importeren. Zojuist heb ik die lijst nog een opgezocht. De versie die ik vond bevatte zo’n 4300 straten waarvan de namen verschillen tussen BAG en OSM.
ter informatie:
Hier de discussie over die straten import in wikidata: https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/RobotMichiel1972_2
en dit is de gebruikte bron: http://opendatanederland.org/nl/dataset/postcode-en-adres-informatie
@de vries, als we die data voor OSM gaan gebruiken, heb ik een klein voorbehoud. We gebruiken dan data uit de derde hand met alle mogelijke onbedoelde missers. Ik heb eenzelfde probleem ook al eens gesignaleerd bij het gebruik van Wikipedia, waar iedereen (ongecontroleerd) aan kan bijdragen. Wat is het nut van andere gegevens naast de BAG, als die bron zelf ook het BAG benut. We moeten dan alles nog een keer controleren, willen we dat ?
Beste Hendrik,
De wikidata=* tag verwijst slechts naar een item op wikidata en kopieert geen gegevens. Omdat wikidata veel meer dan osm geschikt is voor het opslaan van eigenschappen van objecten, is hier veel meer informatie over die objecten te vinden. Neem als voorbeeld de gemeente 's-Hertogenbosch in osm. Behalve de naam en het inwonertal heeft deze relatie niet heel veel beschrijvende tags.
Wel is er de tag wikidata=Q2766547, nu kan je op eens zien wie de burgemeester is en sinds waneer, je vind er een plaatje van het wapen, je kan zien wat de zuster plaatsen zijn en nog veel meer. Als je verder zoekt op wikidata dan kom je bijvoorbeeld op het item van Jheronimus Bosch uit en hier kan je vinden het item van 's-Hertogenbosch staat ingevuld als geboorteplaats.
Probeer je nu eens voor te stellen wat de reactie van de osm community gaat zijn als iemand voorstelt al deze gegeven in osm te importeren. Dat is het mooie van de wikidata tag, met een simpele tag kan je naar een enorme rijkdom aan gegevens verwijzen zonder dat je osm vervuild met een overdaad aan tags die de community nooit zal kunnen onderhouden.
En we hebben het hier al veel vaker gehad over linken vs. importeren. Het is volkomen onzinnig om gegevens te importeren die elders - geheel open source - beschikbaar zijn en die goed worden onderhouden en met een simpele verwijzing in OSM kunnen worden opgenomen.
Wat mij betreft heeft linken de toekomst.
Dus de BAG er maar uit? Ik denk dat het iets genuanceerder ligt.
Nee Frank, want gebouwen zijn objecten “on the ground”, maar de vlag van Den Bosch niet, en ook de burgemeester is niet “on the ground”, net zomin als het aantal inwoners van die stad.
Ik had verwacht dat je dát zou begrijpen als ik het over linken van data heb.
Een kaart laat zien wat er (op zeker moment) is, niet wat er verandert.
(En ja, je kunt ook een kaart maken die veranderingen laat zien, maar dat is niet wat OSM wil laten zien).
Tuurlijk begrijp ik je. Ik had er toch die smiley er achter moeten zetten 
Bij de BAG hebben we het gehad over de wenselijkheid van importeren. Bij de BGT gaat dit geheid ook een rol spelen. Het issue (geen “probleem”) is dat iedereen de grens van wat in OSM thuishoort en wat niet anders ligt. Data die duidelijk niet geografisch is, is vrij duidelijk, maar bij geografische data is dat minder duidelijk. Welk detailniveau moeten we nastreven? Alhoewel het lastig is en in de ogen van velen niet vlot genoeg verloopt, moeten we daar al polderend uit zien te komen.
Ik kan me ook indenken dat het soms juist wel gewenst is om redundantie / overlap in gegevens met Wikidata of andere partijen te hebben. Bijv. adresgegevens van een pand. Maar misschien ook inwoneraantallen, bijv. te gebruiken voor de rendering van labels van woonplaatsen. Anders moet je eerst half Wikidata leegtanken voordat je een kaart kunt renderen. Dat is natuurlijk weer op te lossen door het beschikbaar stellen van dumps. Ik ken Wikidata niet goed, maar dit zouden we natuurlijk met hen kunnen bespreken, of zelf oppakken aangezien het open data is.
En ja, soms houd ik er van om veel vragen te stellen 
Andere partijen kijken ook op deze wijze naar OSM. Laten we erop vertrouwen dat de Wikidata-community het vermogen heeft om adequaat op missers te reageren. Dat geldt voor ieder crowdsourced project.
Ik vind het trouwens wel grappig om te zien in het voorbeeld van de stad en gemeente 's-Hertogenbosch dat er ook data in zit die in OSM thuishoort. Natuurlijk de locatie, maar bij de gemeente bijv. ook “shares border with” en “contains settlement”. Bij de laatste wordt de stad (woonplaats) niet vermeld, ook niet het Q-nummer. We zouden kunnen voorstellen om hun gegevens te verrijken met OSM ID’s.