Idee om wat met BAG te gaan doen

Vincent123 · January 28, 2015, 8:10am

Het leek me wel een goed idee om hetvolgende hier te vragen.

Ik ben een map aan het ontwerpen met TileMill en gebruik hiervoor de OSMBright template.
Als bron heb ik een postgres database ingeladen met osm2pgsql (http://switch2osm.org/serving-tiles/manually-building-a-tile-server-14-04/)
Hiervoor heb ik de PBF van Nederland ingeladen (http://download.geofabrik.de/europe.html)

In de OSMBright template zitten standaard geen huisnummers dus ik ben wat gaan rommelen om dit voor elkaar te krijgen.
Nou viel het mij op dat addr:housenumber maar voor een heel klein percentage is gevuld (48192 van de 11758076 items in de tabel planet_osm_polygon) waarbij wel alle gebouwen netjes te zien zijn.

Ik hoopte dat deze informatie in het PBF bestand zou zitten.
Is dit aanwezig in het orgineel van OSM en is dit niet meegenomen tijdens de extractie bij geofabrik, of moet ik hier zelf extra informatie van de BAG inladen?

Math1985 · January 28, 2015, 8:40am

De adressen zijn als losse nodes ingeladen en niet op de gebouwen geplaatst, dus je kunt ze vinden in planet_osm_point, niet planet_osm_polygon.

Hier de relevante code van de Default rendering:

{
      "name": "housenumbers",
      "srs-name": "900913",
      "geometry": "point",
      "class": "",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "Datasource": {
        "extent": "-20037508,-20037508,20037508,20037508",
        "table": " (SELECT way,\"addr:housenumber\", way_area FROM planet_osm_polygon WHERE \"addr:housenumber\" IS NOT NULL AND building IS NOT NULL\n UNION\n SELECT way,\"addr:housenumber\", NULL AS way_area FROM planet_osm_point WHERE \"addr:housenumber\" IS NOT NULL\n ORDER BY way_area DESC\n ) AS housenumbers",
        "geometry_field": "way",
        "type": "postgis",
        "key_field": "",
        "dbname": "gis"
      },
      "extent": [
        -180,
        -85.05112877980659,
        180,
        85.05112877980659
      ],
      "id": "housenumbers",
      "advanced": {}
    },

#housenumbers {
  [zoom >= 17] {
    text-name: "[addr:housenumber]";
    text-placement: interior;
    text-min-distance: 1;
    text-wrap-width: 0;
    text-face-name: @book-fonts;
    text-fill: #444;
    text-size: 9;
  }
}

Vincent123 · January 28, 2015, 9:55am

Math1985:

De adressen zijn als losse nodes ingeladen en niet op de gebouwen geplaatst, dus je kunt ze vinden in planet_osm_point, niet planet_osm_polygon.

Hier de relevante code van de Default rendering:

{
      "name": "housenumbers",
      "srs-name": "900913",
      "geometry": "point",
      "class": "",
      "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
      "Datasource": {
        "extent": "-20037508,-20037508,20037508,20037508",
        "table": " (SELECT way,\"addr:housenumber\", way_area FROM planet_osm_polygon WHERE \"addr:housenumber\" IS NOT NULL AND building IS NOT NULL\n UNION\n SELECT way,\"addr:housenumber\", NULL AS way_area FROM planet_osm_point WHERE \"addr:housenumber\" IS NOT NULL\n ORDER BY way_area DESC\n ) AS housenumbers",
        "geometry_field": "way",
        "type": "postgis",
        "key_field": "",
        "dbname": "gis"
      },
      "extent": [
        -180,
        -85.05112877980659,
        180,
        85.05112877980659
      ],
      "id": "housenumbers",
      "advanced": {}
    },

#housenumbers {
  [zoom >= 17] {
    text-name: "[addr:housenumber]";
    text-placement: interior;
    text-min-distance: 1;
    text-wrap-width: 0;
    text-face-name: @book-fonts;
    text-fill: #444;
    text-size: 9;
  }
}

Fantastisch, super bedankt!

Gertjan_Idema · January 28, 2015, 7:09pm

De typefout met 0.5.11 ipv 0.5.1 heb ik hersteld.
Krijg je deze foutmelding met de jar bestandan die Johan heeft geupload? Dan vind ik het erg vreemd dat jij hem wel krijgt en Johan en ik niet.

Wat Github betreft: ik nog met git aan het worstelen om de structuur van de branches goed te krijgen. Daarom is github inderdaad nog niet up-to date.

Gertjan_Idema · January 28, 2015, 7:12pm

Bij mij werkt het goed met de de adresnodes. In welk gebied gaat het bij jou fout?

Allroads · January 28, 2015, 9:18pm

Ik had een gebied met een aantal huizen bij Steenwijk Onna getekend. Deze wilde ik ophalen.
Zoals ik al scheef: "Ik heb de twee files op de juiste plaats gekopieerd/overschreven. " En toen JOSM open en kreeg de 0.5.11 melding ok en geen adresnodes.

Nu vanmorgen, PC is uit geweest Windows opgestart, kreeg ik eerst de 0.5.11 melding. Daarna later dat grotere blok melding An unexpected exception occurred … opendataservice…etc.

Nu net voor dat ik dit lees, heb ik opendataservices en osmbag plugin geunchecked, ok, JOSM afgesloten en opgestart, plugin geactiveerd, dit keer imagery Openstreetmap (mapnik) aangezet Anders altijd eerst Bing.

En voila klein polygon getekend download en alle data binnen, dus ook adresnodes en huizen op bag laag.

JOSM 7906 W7

en dan

Nu sluit ik ods-bag af, disable, sluit JOSM af.
Open JOSM, zet imagery Bing maps aan, deze verschijnt , zet ODSbag aan, enable, teken polygon in ODS polygons en haal dat op openstreetmap bag alleen huizen GEEN adresnodes.
DOE IK nog eens precies hetzelfde met Bing, heb ik WEL adresnodes maar GEEN huizen.

Doe ik hetzelfde dan met vooraf aanzetten Openstreetmap (Mapnik) laag, Geen huizen Wel adresnodes.

nu heb ik dat kleine polygon opgeslagen. Om zonder kaart te openen.
En voila, na download heb ik WEL huizen Wel adressen in de BAG laag.
JOSM afsluiten.
Doe ik wederom, met vooraf BING laag aanzetten, heb ik WEL huizen, GEEN adressen.
Nogmaals zonder laag heb ik geen van beide. oeps JOSM afgesloten zonder disable ODS
Probeer ik het nogmaals zonder laag krijg ik wederom de melding.

En ik ben weer terug bij af.

Gertjan_Idema · January 28, 2015, 10:26pm

Ik kom nu ook vergelijkbare problemen tegen. Het lijkt er op dat de plug-in soms de XML niet herkend die hij terug krijgt van de WFS service. Op het eerste gezicht lijkt me dit los te staan van de update van de plug-in, maar ik moet er dieper in duiken om het verder uit te zoeken.

Allroads · January 28, 2015, 11:39pm

Mag er verschil in het afsluiten zijn, het vooraf disable ODS en daarna, JOSM afsluiten, of direct JOSM afsluiten, heeft dit invloed bij het opnieuw opstarten van JOSM?

Gertjan_Idema · January 30, 2015, 3:55pm

Daar zou geen verschil tussen mogen zijn. Bij afsluiten van JOSM wordt eerst ODS afgesloten en ODS slaat niets op behalve het laatst gedownloade gebied.

Commodoortje · January 30, 2015, 5:04pm

Ook bij mij zijn af en toe soortgelijke probleempjes.
Maar het valt me ook op dat niet altijd de geselecteerde polygon wordt gedownload. Soms pakt de plugin een gebied van een vorige polygon.

Allroads · January 30, 2015, 5:35pm

Even opmerking: Het door mij getekende polygon van een paar huizen ligt binnen een ander veel groter polygon die ik gebruikt heb voor de BAG -import.

It_s_so_funny · January 30, 2015, 9:13pm

De functionaliteit werkt bij mij (JOSM 7906) nog steeds net als in de goeie ouwe tijd (= vorig jaar). Wie heeft er een gebied (plaats + straatnaam) voor me dat ik kan testen?

Allroads · January 30, 2015, 9:44pm

dit gebied daar heb ik de problemen

It_s_so_funny · January 30, 2015, 10:13pm

Commodoortje · January 30, 2015, 10:33pm

Ook ik heb dit gebied met de plug-in ingeladen, geen problemen ervaren.
Tevens wil ik aangeven dat mijn bijdrage 1x of 2x voorgekomen is (een actieve polygon werd niet ingeladen, terwijl deze wel geselecteerd was, wel werd een ander stukje ingeladen. Vermoedelijk een voorgaande actieve polygon)

Omdat mijn bijdrage niet concreet is, wil ik aangeven dat dit een incident is geweest. En misschien wel een gebruikersfout van mijn kant.

Het niet inlezen van adresnodes of wel niet inlezen van panden kan natuurlijk ook komen omdat de BAG data niet goed gevuld is als brondata.
@Allroads: geeft jouw aangegeven voorbeeld structureel een download probleem?

Misschien zou je kunnen proberen om even preferences.xml (C:\Users\gebruikersnaam\AppData\Roaming\JOSM) te renamen naar preferences_backup.xml
Als je daarna JOSM start zijn alle gemaakte instellingen weg, en zou je met een schone JOSM kunnen testen.
Natuurlijk kun je daarna je preferences_backup.xml weer terug renamen naar preferences.xml.

Anders wordt het echt zoekwerk voor Gertjan, en omdat de ervaring niet structureel is, is dat natuurlijk vrij lastig om te debuggen.

Gertjan_Idema · January 30, 2015, 10:54pm

Commodoortje:

Allroads:

dit gebied daar heb ik de problemen

Ook ik heb dit gebied met de plug-in ingeladen, geen problemen ervaren.
Tevens wil ik aangeven dat mijn bijdrage 1x of 2x voorgekomen is (een actieve polygon werd niet ingeladen, terwijl deze wel geselecteerd was, wel werd een ander stukje ingeladen. Vermoedelijk een voorgaande actieve polygon)

Omdat mijn bijdrage niet concreet is, wil ik aangeven dat dit een incident is geweest. En misschien wel een gebruikersfout van mijn kant.

Het niet inlezen van adresnodes of wel niet inlezen van panden kan natuurlijk ook komen omdat de BAG data niet goed gevuld is als brondata.
@Allroads: geeft jouw aangegeven voorbeeld structureel een download probleem?

Misschien zou je kunnen proberen om even preferences.xml (C:\Users\gebruikersnaam\AppData\Roaming\JOSM) te renamen naar preferences_backup.xml
Als je daarna JOSM start zijn alle gemaakte instellingen weg, en zou je met een schone JOSM kunnen testen.
Natuurlijk kun je daarna je preferences_backup.xml weer terug renamen naar preferences.xml.

Anders wordt het echt zoekwerk voor Gertjan, en omdat de ervaring niet structureel is, is dat natuurlijk vrij lastig om te debuggen.

Het probleem lijkt niet structureel. De ene keer gaat het goed en een volgende keer geeft het zelfde gebied problemen. Eergisteren had ik het probleem ook toen ik het in QGis probeerde. Daarom heb ik een erg sterk vermoeden dat de instabiliteit aan de server kant zit. (http://geodata.nationaalgeoregister.nl/bag/wfs). Omdat het moeilijk reproduceerbaar is, is het ook erg moelijk om uit te zoeken wat er precies mis gaat.

Dit alles neemt niet weg, dat de manier waarop de plug-in nu reageert als het probleem optreed geen schoonheidsprijs verdient. Ik ga kijken of ik in ieder geval een nette foutmelding kan tonen.

Gertjan

It_s_so_funny · January 30, 2015, 11:12pm

Onder uitschakeling oude diensten in het volgende item https://www.pdok.nl/nl/actueel/nieuws/artikel/21jan15-kadaster-lanceert-nieuwe-bag-viewer staat dat de WFS op termijn wordt uitgeschakeld. Hopelijk kent de community enkele experts (Just / Stefan?) die kunnen helpen met een oplossing.

Gertjan_Idema · January 31, 2015, 1:11pm

Op dit moment zijn er voor zover ik weet 3 BAG WFS services:
geodata.nationaalgeoregister.nl/bagviewer/wfs : Gebruikt door de Geodan bagviewer: http://bagviewer.geodan.nl
bagviewer.kadaster.nl/lvbag/bag-viewer/wfs : Gebruikt door de kadaster bagviewer: http://bagviewer.kadaster.nl

en geodata.nationaalgeoregister.nl/bag/wfs
Deze laatste wordt momenteel gebruikt door de plug-in, omdat deze niet specifiek op een bepaalde (bagviewer) applicatie gericht is.

Uit het artikel op pdok.nl begrijp ik dat geodata.nationaalgeoregister.nl/bagviewer/wfs op termijn komt te vervallen. Of dat ook geldt voor geodata.nationaalgeoregister.nl/bag/wfs wordt uit het artikel niet duidelijk.

Zojuist heb ik geprobeerd of de bag wfs van het kadaster samenwerkt met de plug-in. Dat blijkt niet het geval te zijn. Op zich komt de datastructuur van de kadaster WFS overeen met die van de andere WFS services, maar de service lijkt niet volledig te voldoen aan de WFS specificatie. Waarschijnlijk nog een kinderziekte, maar ik ga navragen bij het Kadaster hoe dat zit.
Daarnaast ga ik kijken of het veel werk is om de keuze van de WFS service configureerbaar te maken in de plug-in.

Ondanks de veelbelovende berichten in het nieuwsartikel over nevenadressen en historische informatie (gesloopte panden!), biedt de nieuwe wfs service geen nieuwe mogelijkheden voor de plug-in. De genoemde gegevens worden opgehaald via een andere service (bag-bevragen) op basis van een pand-id. Het is geen doen om voor een gebiedje met 1000 panden per pand de details op te vragen, om daar vervolgens de 5 nevenadressen of gesloopte panden in dat gebiedje uit te filteren. Daar zullen we voorlopig toch zelf een oplossing voor moeten maken.

Gertjan

Gertjan_Idema · January 31, 2015, 2:21pm

Het probleem lijkt mee te vallen. Een deel van de service werkt alleen over https://, terwijl een ander deel ook over http:// werkt.
bagviewer.kadaster.nl/lvbag/bag-viewer/wfs?request=DescribeFeatureType werkt zowel over http als over https.
bagviewer.kadaster.nl/lvbag/bag-viewer/wfs?request=GetCapabilities werkt alleen over https.

WFS over https werkt nu nog niet in de plug-in, dus dat moet ik nog uitvogelen.

Gertjan

geejee · January 31, 2015, 2:26pm

http:///geodata.nationaalgeoregister.nl/bag/wfs (de "neutrale, niet viewer-gebonden WFS, zoals die vorig jaar april is gelanceerd) blijft gewoon bestaan.
Dat lijkt me ook de meest logische voor dit importdoel.

Voor de iets warmere mappers: de releasekalender van PDOK geeft ook nog aan dat de luchtfoto’s van 2014 dit kwartaal beschikbaar komen (bron: https://www.pdok.nl/nl/actueel/releases/release-planning)).

GeeJee