Hallo,
Dank voor je antwoord. De website draait al op een Google Maps, daar heb ik niets over te vertellen 
Tot voor kort had ik ook nog nooit van PDOK gehoord.
Mijn “probleem” is nu wel dat ik geen bbox gegevens heb, alleen de lat en lon. Een werkend script die de lat/lon omzet naar bbox heb ik nog niet gevonden.
Ik hoopte een beetje dat ik op een andere manier, misschien op basis van adres, zou kunnen opvragen.
Het ligt er ook een beetje aan wat je hebt qua informatie, software, enzovoorts. Als je zeker weet dat de punten die je hebt binnen een pand liggen, kun je de pand-geometrie opvragen uit de WFS met behulp van Contains.
Maar een bbox of bounding box is wat simpeler, hoewel een beetje afhankelijk van de grootte van je gebouw. een bounding box geef je op door middel van de linkeronderhoek en de rechterbovenhoek. Je kunt dus vrij eenvoudig een bbox maken door een waarde van de lat,lon af te halen er en wat bij op te tellen (nou ga ik op m’n donder krijgen van diverse medeforumleden 
).
En natuurlijk hangt het er ook een beetje vanaf wat je met de resultaten wil gaan doen. Als weergave voldoende is, is de WMS misschien al goed genoeg, als je die kunt toevoegen?
Brr
Zolang je meters en graden maar niet door elkaar haalt…
Ik wist het! Maar voor iets simpels als dit kan het geen kwaad over het algemeen, en het maakt het opvragen wel wat simpeler. Overigens nog een voordeel van eenvoudigweg RD…
Inderdaad, eerst de buffer in meters even delen door de afstand van één graad in Nederland:
latbuffer = buffer/110000
lonbuffer = buffer/70000
Je kunt dus vrij eenvoudig een bbox maken door een waarde van de lat,lon af te halen er en wat bij op te tellen
Zoiets had ik ook al bedacht maar wist niet zeker of het haalbaar is.
En natuurlijk hangt het er ook een beetje vanaf wat je met de resultaten wil gaan doen. Als weergave voldoende is, is de WMS misschien al goed genoeg, als je die kunt toevoegen?
Het enige wat ik wil doen is de omtrek van een gebouw tonen op de kaart. De huidige situatie is dat er een Google Maps wordt gebruikt die gevoed wordt met een JS bestand waar de lat/lon in staat om een marker te plaatsen en een stukje HTML om te tonen als men op de marker klikt. Hieraan wil men nu de gebouw omtrek toevoegen.
Inderdaad, eerst de buffer in meters even delen door de afstand van één graad in Nederland
Begrijp ik het goed als ik zeg dat ik de lat/lon 52.364667, 4.892555399999992 heb de buffer wordt berekend als:
latbuffer = 52.364667 / 110000
lonbuffer = 4.892555399999992 / 70000
De bbox is dan 4.892555399999992, 52.364667, lonbuffer, latbuffer ?
Het klinkt misschien een beetje raar allemaal maar het is allemaal nieuw voor mij 
Allen dank voor de hulp.
Nee, als je als lat/lon 52.364667, 4.892555 hebt, en je wilt een buffer om dat punt heen hebben van zeg 5 meter, dan is je latbuffer = 5 / 110000, en je lonbuffer = 5 / 70000. vervolgens is je boundingbox
lat - latbuffer, lon - lonbuffer, lat + latbuffer, lon + lonbuffer. Dat geeft je dan dus ruwweg een rechthoek van 10 x 10 meter (heeel ruwweg, maar Google Maps is toch al niet al te precies, dus dat geeft niet zoveel) met je oorspronkelijke punt in het midden. En dan kun je met die bbox de wfs raadplegen. Let wel op dat als het pand zelf maar 5 x 5 meter is, en er op korte afstand meer panden staan, je dus alles wat in die boundingbox valt terug krijgt.
Overigens is het misschien een beter idee om QGis te installeren, en dan het hele gebied van interesse op te halen uit de wfs, dat is misschien makkelijker als je QGis een beetje kent. Dan is het makkelijker om te onderscheiden welk pand bij welk punt hoort., want dat kun je eenvoudig zien op de kaart. En vanuit QGis kun je eenvoudig een geojson opslaan, of misschien zelfs een KML (die laatste weet ik niet zeker). Maar dat ligt er een beetje aan of je al eens iets met QGis gedaan hebt, de leercurve is misschien te groot.
Geeft toch niks? 't is juist een heel leuk, interessant en uitdagend vakgebied imho. En er zitten hier genoeg mensen op het forum die het leuk vinden om je te helpen hoor, vragen staat altijd vrij
@sbjager Dank voor je uitgebreide uitleg. Het begint allemaal wat te dagen nu
De formule is me duidelijk, helaas krijg ik nul resultaat terug vanuit de BAG WFS. Als ik de bovenstaande lat/lon pak en daar 10 meter bij optel kom ik uit op een bbox van 52.076297286454,4.312083414546,52.076479104636,4.3123691288317 Hierbij gebruik ik de EPSG 4326, die klopt toch? Mis ik nog iets om de info uit WFS te krijgen?
QGis heb ik naar gekeken maar ik moet het automatiseren, dus met de hand gaat niet lukken, daar zijn het ook teveel gebouwen voor. Inderdaad met QGis heb ik nog nooit iets gedaan.
Via verder onderzoek kwam ik ook nog wel uit op de locatieserver (http://geodata.nationaalgeoregister.nl/locatieserver/revgeo?lat=52.364667&lon=4.892555399999992&fg=weergavenaam:vijzelstraat&distance=50) maar met die data kan ik denk ik verder niets tenzij ik het id ergens kan gebruiken om de polygoon coordinaten ergens op te halen.
't is juist een heel leuk, interessant en uitdagend vakgebied imho.
Het is zeker heel leuk, maar ook best veel Verzuip bijna in alle endpoints
Dat is een bbox van 20x20 meter, maar deze valt binnen een erg groot gebouw, waar dat waarschijnlijk nog niet groot genoeg is.
Nog twee andere puntjes:
tsja. dat is een beetje het probleem met bounding boxes vrees ik: of je krijgt teveel, of te weinig, en da’s erg afhankelijk van het pand. En als ik zo eens check, dan liggen je punten ook niet in het pand, dat maakt het nog lastiger. Want hoe weet je dan zeker dat je het juiste pand terug krijgt? Je bovenstaande locatieserver request geeft zowel de Vijzelstraat 32 als de Herengracht 482 terug met exact dezelfde score en afstand. Dat maakt het erg lastig om dit te automatiseren met deze data, tenzij je nog meer informatie hebt over het pand dat je zoekt. Als je de adressen hebt, dan zou ik via de locatieserver het bijbehorende Verblijfsobject opzoeken, dat geeft je een Pand ID, en met dat Pand ID kun je het pand ophalen uit de WFS. Dan ben je er zeker van dat je het juiste pand hebt. Dat zijn weliswaar drie requests per adres, maar de locatieserver is zo snel dat dat geen probleem zal zijn.
Edit: sorry, 4 requests Maar als je ook de adressen hebt, naast de punten, heb ik wel een voorbeeldje voor je.
tenzij je nog meer informatie hebt over het pand dat je zoekt.
Ik heb ook de adresgegevens van het pand. Ik zie nu dat ik dat nog helemaal niet vermeld had.
Maar als je ook de adressen hebt, naast de punten, heb ik wel een voorbeeldje voor je.
Heel graag. Ik denk dat we er bijna zijn
De dingen waar je geen weet van hebt als je ze nooit gebruikt, wat een openbaring is dit dan wel weer. 
OK, Vijzelstraat 32 Amsterdam als voorbeeld.
Eerst de locatieserver:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=Vijzelstraat 32 Amsterdam
dat geeft je het volgende json terug:
{
“response”:{“numFound”:1,“start”:0,“maxScore”:19.388288,“docs”:[
{
“type”:“adres”,
“weergavenaam”:“Vijzelstraat 32, 1017HL Amsterdam”,
“id”:“adr-26870471e0b53450b8be0128a11aeb44”,
“score”:19.388288}]
},
En nog wat, maar dat is niet interessant voor nu. de ID is wat we vervolgens nodig hebben om de details op te vragen:
Dat geeft je de volgende json terug:
{
“response”:{“numFound”:1,“start”:0,“maxScore”:15.750006,“docs”:[
{
“bron”:“BAG”,
“woonplaatscode”:“3594”,
“type”:“adres”,
“woonplaatsnaam”:“Amsterdam”,
“wijkcode”:“WK036303”,
“huis_nlt”:“32”,
“openbareruimtetype”:“Weg”,
“buurtnaam”:“Gouden Bocht”,
“gemeentecode”:“0363”,
“rdf_seealso”:“http://bag.basisregistraties.overheid.nl/bag/id/nummeraanduiding/0363200012162038”,
“weergavenaam”:“Vijzelstraat 32, 1017HL Amsterdam”,
“straatnaam_verkort”:“Vijzelstr”,
“id”:“adr-26870471e0b53450b8be0128a11aeb44”,
“gekoppeld_perceel”:[“ASD06-I-8025”],
“gemeentenaam”:“Amsterdam”,
“buurtcode”:“BU03630301”,
“wijknaam”:“Grachtengordel-Zuid”,
“identificatie”:“0363010012159931-0363200012162038”,
“openbareruimte_id”:“0363300000005292”,
“waterschapsnaam”:“Waterschap Amstel, Gooi en Vecht”,
“provinciecode”:“PV27”,
“postcode”:“1017HL”,
“provincienaam”:“Noord-Holland”,
“centroide_ll”:“POINT(4.89239814 52.3645642)”,
“nummeraanduiding_id”:“0363200012162038”,
“waterschapscode”:“11”,
“adresseerbaarobject_id”:“0363010012159931”,
“huisnummer”:32,
“provincieafkorting”:“NH”,
“centroide_rd”:“POINT(121297.519 486412.465)”,
“straatnaam”:“Vijzelstraat”}]
}}
Hiervan hebben we het adresseerbaarobject_id nodig, daarmee kunnen we het Verblijfsobject ophalen uit de BAG wfs. Daarvoor maken we een filter xml aan:
<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<fes:PropertyIsEqualTo>
<fes:PropertyName>identificatie</fes:PropertyName>
<fes:Literal>0363010012159931</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
En dat gooien we naar de BAG:
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?service=WFS&version=2.0.0&request=GetFeature&typename=bag:verblijfsobject&outputFormat=json&filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd"> <fes:PropertyIsEqualTo><fes:PropertyName>identificatie</fes:PropertyName><fes:Literal>0363010012159931</fes:Literal></fes:PropertyIsEqualTo></fes:Filter>
Kun je eventueel ook met een POST doen als het te lang word, maar alleen op een ID filteren valt meestal wel mee. Hierop krijg je de VBO informatie terug:
{
“type”: “FeatureCollection”,
“numberMatched”: 1,
“name”: “verblijfsobject”,
“crs”: { “type”: “name”, “properties”: { “name”: “urn:ogc:def:crs:EPSG::28992” } },
“features”: [
{ “type”: “Feature”, “properties”: { “gid”: 3570770, “identificatie”: “0363010012159931”, “oppervlakte”: 17442, “status”: “Verblijfsobject in gebruik”, “gebruiksdoel”: “bijeenkomstfunctie”, “openbare_ruimte”: “Vijzelstraat”, “huisnummer”: 32, “huisletter”: “”, “toevoeging”: “”, “postcode”: “1017HL”, “woonplaats”: “Amsterdam”, “bouwjaar”: 1924, “pandidentificatie”: “0363100012165077”, “pandstatus”: “Pand in gebruik”, “rdf_seealso”: “http://bag.basisregistraties.overheid.nl/bag/id/verblijfsobject/0363010012159931” }, “geometry”: { “type”: “Point”, “coordinates”: [ 121297.519, 486412.465 ] } }
]
}
En daarvan is de pandidentificatie belangrijk. Daarmee kunnen we het pand ophalen, en dat kunnen we direct in EPSG:4326 doen - dus je eindresultaat is meteen wat je nodig hebt. Eventueel kun je ook nog opnemen in welk formaat je het eindresultaat terug wil hebben, de BAG wfs ondersteund het volgende lijstje:
In dit voorbeeld vraag ik json op in EPSG:4326, wederom met een filter:
<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<fes:PropertyIsEqualTo>
<fes:PropertyName>identificatie</fes:PropertyName>
<fes:Literal>0363100012165077</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Filter>
https://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?service=WFS&version=2.0.0&request=GetFeature&typename=bag:pand&srsName=urn:ogc:def:crs:EPSG::4326&outputFormat=json&filter=<fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd"> <fes:PropertyIsEqualTo><fes:PropertyName>identificatie</fes:PropertyName><fes:Literal>0363100012165077</fes:Literal></fes:PropertyIsEqualTo></fes:Filter>
en dat geeft je het volgende resultaat terug:
{
“type”: “FeatureCollection”,
“numberMatched”: 1,
“name”: “pand”,
“features”: [
{ “type”: “Feature”, “properties”: { “gid”: 3751862, “identificatie”: “0363100012165077”, “bouwjaar”: 1924, “status”: “Pand in gebruik”, “gebruiksdoel”: “bijeenkomstfunctie”, “oppervlakte_min”: 338, “oppervlakte_max”: 17442, “aantal_verblijfsobjecten”: 2, “rdf_seealso”: “http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012165077” }, “geometry”: { “type”: “Polygon”, “coordinates”: [ [ [ 4.892448247193042, 52.364601148030161 ], [ 4.892477848840883, 52.36468641247194 ], [ 4.892580792420174, 52.364983078078957 ], [ 4.892560943549834, 52.365004053418147 ], [ 4.892206423363819, 52.365051177637284 ], [ 4.892203453250191, 52.36505156966949 ], [ 4.892170752233234, 52.365055917845602 ], [ 4.892163062134366, 52.365056946249247 ], [ 4.892130522803257, 52.365061277114719 ], [ 4.892080361643198, 52.364922566478548 ], [ 4.892118604885792, 52.364917567419504 ], [ 4.892151334465833, 52.364913282291468 ], [ 4.892154936762576, 52.364912812013898 ], [ 4.892135330695073, 52.364856772442145 ], [ 4.892133154578334, 52.364857059939339 ], [ 4.891953076379428, 52.364342136858696 ], [ 4.891956680337729, 52.364341513802763 ], [ 4.891936598228092, 52.364284762168573 ], [ 4.89189295857533, 52.364290547491485 ], [ 4.891844625228277, 52.364153956491847 ], [ 4.892249877837053, 52.364100277669777 ], [ 4.892279091168968, 52.364113701615459 ], [ 4.89238190458375, 52.364409953457155 ], [ 4.892411591156121, 52.364495478918528 ], [ 4.892429911812327, 52.36454831344534 ], [ 4.892448247193042, 52.364601148030161 ] ] ] } }
]
}
En dat is volgens mij redelijk waar je naar op zoek bent. Goed, het kost 4 requests, en je zou de locatieserver stappen kunnen overslaan door direct te filteren op adres bij het opvragen van het VBO. Ik vind het wat makkelijker om eerst naar de locatieserver te gaan, omdat daar ok interessante extra informatie bij mee komt (percelen, waterschap, enz). Maar bovenstaande is goed in een scriptje te zetten dat simpelweg een aantal adressen afwerkt.
En dat is volgens mij redelijk waar je naar op zoek bent.
Dat is inderdaad waar ik naar op zoek ben. Hiermee kan ik het wel in een script bouwen. Enorm bedankt voor alle geduld en hulp.
Auw! 15 cijfers achter de komma (0,1 nanometer), dat zou genoeg zijn om individuele atomen aan te kunnen duiden (als ze voldoende stil zouden blijven staan).
Ja dat is niet best; gek genoeg geeft de GML output 6 cijfers achter de komma:
<gml:posList srsDimension="2">
52.364601 4.892448 52.364686 4.892478 52.364983 4.892581 52.365004 4.892561 52.365051 4.892206 52.365052 4.892203 52.365056 4.892171 52.365057 4.892163 52.365061 4.892131 52.364923 4.892080 52.364918 4.892119 52.364913 4.892151 52.364913 4.892155 52.364857 4.892135 52.364857 4.892133 52.364342 4.891953 52.364342 4.891957 52.364285 4.891937 52.364291 4.891893 52.364154 4.891845 52.364100 4.892250 52.364114 4.892279 52.364410 4.892382 52.364495 4.892412 52.364548 4.892430 52.364601 4.892448
</gml:posList>
Ik zal het hier aankaarten.
En als je GML in RD opvraagt, krijg je ook 6 decimalen:
<gml:Polygon gml:id="pand.bag:0363100012165077.1" srsName="urn:ogc:def:crs:EPSG::28992">
<gml:exterior>
<gml:LinearRing>
<gml:posList srsDimension="2">
121301.013000 486416.543000 121303.094000 486426.016000 121310.331000 486458.976000 121308.995000 486461.319000 121284.884000 486466.727000 121284.682000 486466.772000 121282.458000 486467.271000 121281.935000 486467.389000 121279.722000 486467.886000 121276.200000 486452.476000 121278.801000 486451.902000 121281.027000 486451.410000 121281.272000 486451.356000 121279.894000 486445.130000 121279.746000 486445.163000 121267.089000 486387.955000 121267.334000 486387.884000 121265.923000 486381.579000 121262.955000 486382.243000 121259.559000 486367.068000 121287.121000 486360.907000 121289.121000 486362.387000 121296.349000 486395.301000 121298.436000 486404.803000 121299.724000 486410.673000 121301.013000 486416.543000
</gml:posList>Tsja. Als ik heel eerlijk ben, let ik er meestal al niet meer op, want er zijn nogal wat software pakketten die heel slecht omgaan met decimalen. ArcGis bijvoorbeeld slaat zelfs in RD 10 of 11 decimalen op in de database, en je kunt dat niet ergens instellen. Van de zotte af en toe. Gelukkig gebruik ik heel veel FME en die heeft een transformer die coordinaten afrond: als ik ergens geometrie ophaal, zet ik dat ding er altijd standaard achter. En het is zo zonde, want niet alleen voegt het niets toe, het vraagt beduidend meer ruimte qua opslag, en het maakt ook vergelijkingen van geometrie (waarbij je geen tolerantie kunt opgeven - ja FME, ik kijk naar jou!) vele malen lastiger. Terwijl in de praktijd een punt dat 1 millimeter naast een ander punt gelijk is aan het eerste punt, maar dit soort decimaal-aantallen voor software dus never nooit. Als oud-landmeter irriteert me dat mateloos…
Toch is het wel vreemd dat 1 wfs zoveel verschillende output-decimalen kent (alles wat ik hier heb gepost, komt copy-pasta uit de wfs…)
Dat software onderwater floating-point-variabelen gebruikt en dus heel veel decimalen is niet zo’n probleem (mits er inderdaad toleranties gebruikt worden), maar bij presentatie van coördinaten op het scherm of bij opslag in ascii-uitwisselingsformaten wordt het onhandig.
Het lijkt er op dat men zomaar wat doet. Al kunnen er goede redenen zijn om de ene keer 15 decimalen te gebruiken en de andere keer 6. Maar 6 decimalen lijkt in dit geval me voor de BAG wat weinig, dat kan er bijvoorbeeld voor zorgen dat een erker opeens niet meer loodrecht op de gevel lijkt te staan. Ik denk dat het door onwetendheid komt. Ingewikkeld is het namelijk niet. Uitrekenen dat 6 decimalen een resolutie van 11 cm noord-zuid en 7 cm oost-west geeft in Nederland (52°NB) is gewoon middelbareschoolwiskunde.
R = 6371km
0.000001°/360° × 2πR = 11cm
11cm × cos(52°) = 7cm
Helemaal mee eens. Men neemt de default van wat de software aan output geeft, en denkt er verder niet over na. Ik denk dat zelfs voor de BAG in RD 3 decimalen er al minstens 1 teveel is: ga maar eens goed kijken naar de hoek van een bakstenen bouwwerk…
Maar we hebben dit draadje engiszins gekaapt, vrees ik. Weliswaar met een relevante en interessante discussie, maar toch: niet heel beleefd. Hoewel @rolandd wel verder kan geloof ik Geen dank, graag gedaan ! En je weet nu waar je terecht kunt als je nog andere vragen hebt.
Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.