Afvalcontainers Arnhem opvragen en importeren

Communities Nederland (Netherlands)
1

Gemeente Arnhem is een tijd bezig met ‘omgekeerd inzamelen’ waarbij restafval niet meer in een kliko gaat, maar naar een ondergrondse container moet worden weggebracht. Hiervoor zijn over het afgelopen jaar veel extra ondergrondse containers geplaatst. En die containers staan lang niet allemaal in OpenStreetMap.

Dit lijkt me een leuk en haalbaar project om een dataset op te vragen en te importeren in OSM. Dit is voor mij de eerste keer. De data opvragen kan via een Open Data verzoek (verwijst door naar data.overheid.nl) Als backup is er nog de Wet hergebruik overheidsinformatie (Who), maar ik verwacht niet dat ik me daarop hoef te beroepen, daar is juist het gestroomlijnde Open Data loket. Ik hoop dat een van jullie me kunnen voorzien van feedback.

De gemeente publiceert al informatie over de containers op een webpagina en publiceert een interactieve kaart met de containers en metadata.

Ik heb de Import Guidelines al doorgenomen. Die zijn op zich duidelijk, maar Ik zal veel stappen hiervan nog moeten doorlopen, dus tips zijn welkom.

Verzoek
Wat aandachtspunten die ik me voor kan stellen bij het verzoek:

  1. Bij voorkeur voegen ze het zelf toe aan Openstreetmap (scheelt mij werk :wink: )

  2. OSM Compatible licentie, bijvoorbeeld CC-BY-4.0

  3. Voorkeur voor een direct bruikbaar importformaat (GeoJSON?)

  4. Alle metadata over gebruik van de containers

  5. Extra metadata of de container ondergronds is, want dit is relevant voor OSM, maar staat niet in de huidige kaart van de gemeente.

  6. Extra metadata of de container een toegangspas vereist. Bijvoorbeeld wel voor restafval, maar niet voor glas. Papier en GFT weet ik niet zeker.

Dataformaat
Ik heb nog niet eerder data geïmporteerd in Openstreetmap. Ik heb wel eens in Python met GeoJSON gewerkt, los van Openstreetmap. Zou GeoJSON een goed formaat zijn om op te vragen, of is een ander formaat logischer? Het lijkt me dat JOSM hier de meest handige tool voor is? Ik las ergens iets over het omzetten van GeoJSON naar OSM XML om te kunnen importeren in JOSM. Heeft iemand hier meer informatie over?

Tags
De tags die in de interactieve kaart worden weergegeven bevatten interessante informatie. Maar wel is de vraag hoeveel informatie hiervan interessant is voor OSM. Dit zou in de Recycling amenity moeten. Twee voorbeelden van tag sets:


Afvalcontainer: Restafval_ZW
Nummer: 633
Adres: Fontuinkruidstraat naast 49(Veenwortelstraat)
Afvalstroom: Restafval_ZW
Zwerfvuilklep: Ja
Buurt: Malburgen-West



Afvalcontainer: Papier
Nummer: 1,928
Adres: Het Maisveld 22 - 60
Afvalstroom: Papier
Zwerfvuilklep: Nee
Buurt: Klingelbeek

Mijn ideeën bij die tags:

  • Afvalcontainer / Afvalstroom Liefst bij generieke categorieën van afval blijven, omdat gemeentelijk beleid kan wijzigen. Bijv. wel of geen etensresten in GFT.

  • Nummer Zou in een loc_ref: tag geplaatst kunnen worden, evt. loc_ref:cont_nr Of ik kan bij de gemeente navragen onder welke naam zij deze tag registreren, ter inspiratie. Dit nummer is zichtbaar op de container zelf, dus wellicht relevant om over te nemen. Iemand tips hiervoor?

  • Adres Is een vrij veld om een plaats aan te duiden. Lijkt me overbodig om over te nemen.

  • Zwerfvuilklep Dit is een kleine klep die zonder pasje bruikbaar is, voor zwerfvuil. Ik zie hier nog geen tag voor gebruikt. Ik kan het als issue aanmerken, maar hoeft voor nu niet overgenomen te worden. Misschien is het zinvol dit als notitie op te nemen indien een zwervuilklep aanwezig is, mocht hier toch een tag voor komen?

  • Buurt Net als adres af te leiden van locatie, dus kan volgens mij ook genegeerd worden.

  • Underground De kaart van de gemeente laat niet zien of een container ondergronds is, maar dat is voor OSM een relevante tag. Volgens mij zijn in Arnhem de meeste, zo niet alle containers ondergronds. Ik kan dit meenemen in het dataverzoek.

  • Toegang De restcontainers moeten met een pasje geopend worden en die functioneert tegen betaling. Ik kan zo snel niet de goede tag hiervoor vinden om dit aan te merken. Ook zal ik voor de andere typen op moeten vragen hoe de toegang geregeld is. Containers voor glas zijn bijvoorbeeld altijd bruikbaar.

Ik ben benieuwd naar jullie feedback en tips.

In mijn achterhoofd heb ik vergelijkbare dataverzoeken voor brievenbussen, bankjes, prullenbakken, paden tussen huizen, lantaarnpalen, brandkranen (in NL ondergronds), bomen, putdeksels, parkeerplaatsen, AEDs, fietsenrekken, camera’s, verkeersborden, reclamezuilen, terrassen, zonnepanelen, etc. Ik vermoed dat er veel informatie bij publieke instanties is geregistreerd die nog niet in OSM te vinden is. En een dataset kan volgens mij goed bestaan naast het mappen zelf.

2

Je bedoeling is ongetwijfeld goed… maar bij bulkimport moet je je altijd weer afvragen wie het vervolgens gaat onderhouden. Voor de import van gebouwen is een heel systeem opgetuigd. Dat zie ik bij reclamezuilen e.d niet gebeuren… Vandaar dat we wat behoudend zijn op dit gebied.
Maar er zal vast nog wel meer reactie komen.

3

Ja, dat begrijp ik. Zo heb ik een paar maanden geleden een brievenbus verwijderd die er niet meer stond. Die was al langer weg, maar het duurde een tijd voordat me opviel dat de data niet meer klopte. En al die tijd was de kaart incorrect.

Bij AEDs kan ik me helemaal voorstellen dat je voorzichtig moet zijn om dit toe te voegen. Het lijkt me waardevol om dat in OSM te hebben, maar de Hartstichting houdt nu zelf een kaart bij. Als iemand de verkeerde kant op rent voor een AED omdat de data niet op orde is, kan dat een leven kosten. (Het idee is dat meerdere personen uit de buurt een oproep krijgen en onderweg een AED meepakken, dus hopelijk met een backup.) De kwaliteit van de data lijkt me daarvoor belangrijker dan de wens om het in OSM te hebben.

Is het denkbaar dat dat ‘systeem’ breder ingezet kan worden om andere datasets in sync te houden? Ik heb via Pic4Review al een mission in Utrecht gezien waar een dataset gevalideerd kan worden. Als er al een object in de buurt is, wordt dat opgemerkt, zodat bijvoorbeeld onnodige dubbelingen worden voorkomen. Zoiets zou automatisch kunnen worden aangemaakt als er een nieuwe dataset is.

Misschien heb ik hier een interessante, maar off-topic discussie aangewakkerd door die laatste alinea. Dus even terug naar de oorspronkelijke vraag: denk je dat het hier ook al speelt of dit onderhoudbaar is, of is dat meer voor mijn voorbeeld van reclamezuilen?

Waarschijnlijk zullen er in de komende jaren nog wat containers bijkomen om loopafstanden kort te houden, en omdat er GFT-containers voor flats bij zullen komen (want ze betalen anders onnodig als ze dat afval bij het restafval stoppen). Maar kleine wijzigingen kunnen evt. individueel worden bijgehouden, of door over 1 of 2 jaar weer een bulk-import te doen. Ik ben benieuwd hoe je hierover denkt. Ik zou me ook kunnen focussen op andere elementen in de publieke ruimte, maar in dit geval leken de objecten me eenvoudig (node, beperkt aantal tags) en de hoeveelheid nog te overzien.

4

Ik heb ook wat gestoeid met import van eenvoudig ogende datasets.

De eerste moeilijkheid is: de exacte geolocatie. Heb je die? Een adres zegt niks.

De tweede moeilijkheid is, per objekt kontroleren of het al bestaat, mogelijk met een iets andere positie en andere eigenschappen, door een mapper ter plekke ingevoerd. Zo ja: wil je overschrijven, wil je samenvoegen, wil je de nieuwe overslaan? Ik kon dat niet automatisch beslissen; handmatige ingreep was zowizo nodig.

Derde moeiljkheid: relatie tot omgeving die al ingevoerd is. Heel veel kleine moeilijkheidjes: vaak kleine aanpassingen nodig, zowizo in de positie, maar vaak ook in de al ingevoerde gegevens die niet altijd even accuraat zijn. Dat is dan jouw fout niet, maar je wil toch geen container plaatsen in een vijver of op een trambaan, dus daar moet je wat aan doen.

De enige software-ondersteunde werkwijze die ik kon bedenken was: een concordantielijst laten maken (dataset vergelijken met OSM) waarbij allerlei standaard- en zelfgedefinieerde validaties kunnen worden toegepast, eventueel met een suggestie voor oplossing erbij voor eenvoudige en veel voorkomende verschillen.

Dan kan ik me voorstellen dat sommige verschillen een standaardoplossing hebben (vervangen mbv een tagmappng; overslaan; alleen ontbrekende atrributen toevoegen;) en dat de rest handwerk vereist. Aanpassing van de precieze geolokatie vereist vaak al handwerk, al zou je ook kunnen toevoegen gevolgd door handmatige verschuiving, voordat je uploadt.

Mocht je wijzigingen doen in OSM, en je komt later met een nieuwe export waar alles weer instaat, dan staan alle verschillen er ook weer in. Je moet alles weer checken, want er kunnen ook in de data die eerder zorgvuldg overgenomen en goedgemaakt was, van beide kanten af nieuwe verschillen zitten.

5

Vraag je ook af wat het nut is (los van de andere tegenargumenten): de lokale bewoner weet best waar de dichtstbijzijnde voorziening is en heeft daar OSM niet voor nodig. Voor alle andere gebruikers van OSM nutteloze informatie derhalve.

Ik zou het niet doen.

6

Bedankt voor de feedback, dat heeft me wel aan het denken gezet.

Het bijhouden van verschillen lijkt me hier minder een probleem; de locaties zijn nauwkeurig en lijken goed uit te lijnen met de gebouwen en parkeerplaatsen op de ESRI kaart. Daarmee vermoed ik dat de locaties dus ook goed uitkomen op OSM, omdat er dezelfde BAG-data aan ten grondslag zal liggen.

Tja, waarom? De data is al geprepareerd beschikbaar bij de gemeente, dus het lijkt me een eenvoudige manier om meer details in OSM te krijgen.

@Martin Borsje: beetje flauw, maar waar ligt die grens dan wel? Geldt dat ook voor brievenbussen? kappers? supermarkten? Wat is de norm van data die wel in OSM hoort, en welke (nog) niet? Ik zou bijvoorbeeld ook alleen de glasbakken kunnen importeren, die wel publiek toegankelijk zijn.

Is er misschien een alternatieve soort geodata, bekend bij de gemeente, die wel interessant is om over te nemen? Ik zie op die ESRI kaart ook de parkeerplaatsen, plantsoenen, bomen en de middenbermen. (ook interessant, de wegen lijken ingetekend als area, niet als line). Of misschien de plaatsen van brievenbussen opvragen en tegen de huidige locaties aan houden.

Of kan ik bijdragen aan een initiatief dat al loopt?

7

Ik weet niet waarom je het een beetje flauw vindt.

Het bijhouden van de verschillen is echt wel een topic: als de importeur OSM ‘verlaten’ heeft: wie neemt dan de rol op zich dit alles te updaten?

Er is geen keiharde grens maar in mijn ogen common sense.
Natuurlijk mogen er meer details in OSM komen, maar of dat met behulp van (massale) mechanische imports dient te gebeuren waag ik te betwisten.
Laatst in Tilburg is een dergelijk massale import uitgevoerd tegen alle regels in: geen verificatie in het veld; landuse over bestaand landuse heen (gewoon laten staan dus), kerbs wegen kruisend, 40*40 cm groen (een boom) als grass geïmporteerd, individuele parkeerplaatsen bij woningen en zo kan ik wel even doorgaan. Het heeft velen, onder wie ik, veel werk gekost dit op te ruimen; de importeur was niet bereid zelf zijn werk op te ruimen.

Het intekenen van highways als area is een interessant topic. Voor routering is nog steeds een lijnelement nodig (bijvoorbeeld highway=pedestrian|area=yes routeert (nog) niet. De tag width=* zou imho voor de rendering ook al zinvol kunnen zijn (naast lanes=* natuurlijk)

De vreugde in en de meerwaarde van OSM dient imho niet te komen uit het mechanisch importeren “omdat het kan”.
OSM is geen back-up database van de overheid.

Maar ik kan het mis hebben.

8

Ik heb er nog even wat data bij gezocht voor context. Via Overpass (was voor mij nieuw, maar is erg bruikbaar) vind ik 271 recycling containers in Arnhem:


node
  [amenity=recycling]
  ({{geocodeBbox:Arnhem}});
out;

Waarvan 112 voor glas:


node
  [amenity=recycling]["recycling:glass_bottles"=yes]
  ({{geocodeBbox:Arnhem}});
out;

In de dataset van de gemeente vind ik totaal 1490 containers, waarvan 80 voor glas. Omdat dit minder zijn dan in OSM, doet me dit vermoeden dat in OSM enkele containers voor restafval ook de tag voor glas hebben gekregen. Of dat er ondertussen containers zijn vervangen.

Misschien is het sowieso dan niet verkeerd om die datasets een naast elkaar te leggen om de registratie in OSM te controleren.

9

@Martin Borsje, sorry voor het misverstand. Ik bedoelde te zeggen dat de opmerking die ik ging maken wat flauw zou zijn. Jouw opmerking is een rake.

Ik denk erover voorzichtig aan verder te gaan met dit idee, en dan maar te zien wat het brengt. Ik kan bestaande containers ermee valideren, en een paar toevoegen waar dat zinnig is (glas, textiel). Maar een klakkeloze bulk-import is niet wenselijk.

10

Ik ken de situatie in Arnhem niet. Hier in Groningen zou ik met zo’n dataset wel wat kunnen. Er staan veel amenity=post_box-nodes op de kaart, waar allang geen echte brievenbus meer hangt. Bij mij in de buurt loop ik dat zo’n beetje na (natuurlijk met hulp van Overpass) en verwijder het een of ander. Een (bruikbaar gelicenseerd, openbaar) dataset zou veel werk kunnen schelen.

11

@smootheFiets: dat herken ik. Na aanleiding van deze thread heb ik gisteren OSM eens tegen de website van PostNL aangehouden. OSM bevat lang niet alle brievenbussen, maar ook is er een handvol brieven in OSM niet te vinden op de website van PostNL. Ik heb er voor nu maar opmerkingen bij geplaatst, omdat er geen openbare dataset met licentie voor beschikbaar is. Misschien wil jij die aanvragen bij https://data.overheid.nl/ voor heel Nederland?

Ik heb zojuist de aanvraag voor de containers ingediend. Ik ben benieuwd hoe dit verder gaat.

12

In het verleden (2016) is er al een keer uitvoerig over brievenbussen gesproken.

13

Hi nicorikken,
Je kunt doublures of missende objecten mooi vinden aan de hand van een kaart, door die als route kaart te gebruiken om ter plaatse het een en ander te bezien.
Zo wordt OSM echt beter dan andere “kaarten”, levende verkenning is altijd beter dan een digitale copy en rijker aan detailering.

14

Los van een lading brievenbussen die al of niet op de juiste plaats komen… is niet elke bron toegestaan om te gebruiken. PostNl??
Bij de laatste import van lantaarnpalen vond ik er 66.000 terug ergens in de Atlantische Oceaan voor de kust van Nigeria. Misschien een nulletje teveel… maar toch. Bezint eer ge begint.
Lees goed de oude draadjes door dan hoeven we het wiel niet opnieuw uit te vinden.

15

Ondertussen is de data van de afvalcontainers onder een geschikte licentie gepubliceerd. Indrukwekkend hoe snel mijn verzoek is afgehandeld. Men gaat nog kijken of informatie over toegang ook wordt geregistreerd, alsmede of het een ondergrondse container betreft. Ik zal de komende tijd eens kijken hoe ik de data in JOSM kan laden en zal de rest van de stappen van de officiële import guidelines doornemen.

16

CC-BY is geen geschikte licentie, zie wiki.

17

Wat een aantal mappers al proberen te zeggen, wil ik ook nog een plasje er overheen doen.

Wees voorzichtig met automated edits, en vooral imports van bulkdata.
BAG is vanaf het begin goed gecoördineerd en gedocumenteerd, maar vooral ook bediscussieerd.
Tevens is elke importeur die eraan heeft meegewerkt verantwoordelijk voor zijn deel van het geïmporteerde.

Laten we vooral geen poging doen om alle mogelijk vrijgegeven data (CC0), ook werkelijk te importeren.

CC-BY(4:0) is inderdaad open data, maar met restricties die niet te gebruiken zijn voor OSM.

Ooit heb ik een draadje gestart hierover.

https://forum.openstreetmap.org/viewtopic.php?id=54974

18

Stom van me, ik had CC-BY-4.0 gelezen in het forumonderwerp 3D Basisbestand Volledig, akkoord beschikbaarheid voor Openstreetmap. Maar nu ik er nog eens naar kijk, lees ik dat er juist een andere licentie overeen is gekomen om import in OSM mogelijk te maken. Bedankt alphensebezorger en Commodoortje dat jullie me hierop wijzen.
Ik heb contact opgenomen om de data onder een andere licentie te publiceren, gebaseerd op de Import/ODbL Compatibility wiki pagina.

19

3 posts were split to a new topic: Import onder- en bovengrondse locaties Amstelveen

20

onder andere omdat die brievenbusimport van 2016 is teruggedraaid (de adressen op de site van PostNL kloppen vaak niet) had ik nog wat recenter dan 2016 eens dit geprobeerd (ook omdat het gewoon leuk was om dat uit te zoeken)

Geen bulk import, maar een poging tot een hulpmiddel voor handmatig bijwerken van brievenbussen.

Ik doe nog regelmatig een update (gelukkig nu semi automatisch met 1 script, ik heb geen server om een script dit dagelijks automatisch te laten doen)

https://qgiscloud.com/kaartenliefhebber/postnl/?l=osm_stats%2Cosm_post_box_postnl%2Cosm_post_box_no_operator%2Cosm_post_box_other%2Cpost%20boxes%20according%20to%20PostNL%2Cpakket_en_briefautomaat_PostNL_met_bus%2Cpakket_en_briefautomaat_PostNL_zonder_bus&bl=mapnik&t=postnl&e=217416%2C6600900%2C725416%2C6838761

ben zelf zo nu en dan bezig met Zeeland / West-Brabant, alles doen wordt me wat te veel :wink:

1 Like