Geometrie Items sluiten in geval van quads niet aan?

Besten,

Ik kom erachter dat de items van deze dataset qua “features” → “geometry” → “coördinates” niet de coordinates van aanliggende geometry bevat, daar waar de coördinates van zo’n item quad-meshes kunnen vormen. Dat is voor zover ik kan zien voor alle geometrie die normaliter ge-tri-meshed wordt om tot een oppervlak te komen wel zo.

Denk bijvoorbeeld aan de Pand-items (vaak rechthoekig). Daar worden de coordinates van andere items die daar op zouden aansluiten overgeslagen. Het levert in 2D, zoals veel gebruikers hem waarschijnlijk gebruiken geen probleem op, want dan lijken de Items netjes aan te sluiten. Wij ontsluiten hem echter in 3D, en dan krijg je “luchtgaatjes” tussen de items.

Nu kunnen we dit vast met een geitenpaadje verhelpen, maar ik vroeg me af of het niet verstandiger is dit bij de bron aan te pakken? Het zou kunnen dat andere partijen daar in de toekomst ook bij gebaat gaan zijn.

Met vriendelijke groet en bij voorbaat dank voor reactie,

Thomas Broos
Moondoor BV


Hoi Thomas, ik heb niet direct een antwoord op je vraag maar ben wel benieuwd naar welke dataset je refereert. Is dit 3D BGT a.k.a. ‘Basisvoorziening’ Kadaster? En hoe kom je aan die bomen?

Hoi Halam,

Ik heb het over de OGC API van de BGT. Dus niet de “Basisvoorziening Kadaster”, die werkt nog op AHN4.

Mvg, Thomas

Ik wist niet dat BGT (via OGC api) waarden voor z kon doorgeven.

Hoi hoi,

Dat doet ie ook niet! AHN5 daarintegen wel. De basisvoorziening van het kadaster zit nog op AHN4 en dat is me te oud.

Met die informatie als achtergond… iemand? :slight_smile:

Mvg, Thomas

Interessante case.

Je gebruikt de BGT OGC API Features geef je aan. Ter controle: Welke CRS gebruik je? De native CRS van de BGT is EPSG:28992 (Rijksdriehoek).

Goedemorgen,

We gebruiken de 28992 inderdaad. Ter verduidelijking: er is in top-view (2d) dus niks aan de hand he. Alleen als je genoemde punten een hoogte meegeeft gaan er in 3d gaatjes zitten in de z-richting, omdat de geometrie daar niet “netjes” langs alle punten van de buur-geometrie loopt.

Mvg, Thomas

Zomaar een paar ideeën:

Past je eigen software toevallig nog een “simplificatie” functie toe? Dat kan heel goed verschillende resultaten geven voor gezamenlijke grenzen van buurobjecten.

Kan het zijn dat idealiseerbare objecten anders omgezet worden naar 3d? Van een pand kun je verwachten dat deze “waterpas” is, en als de software dat forceert, dan blijft je pand plat, maar de buurobjecten niet.

Verder staat de BGT OGC API toe om JSON, of JSON-FG op te vragen. JSON-FG laat meer soorten geometrie-typen toe. Kan zijn dat als een geometrie-type niet in JSON past, maar je software dat wel vraagt, dat er dan nog een conversie plaatsvindt die niet gewenst is.

1 like

Ha Oscar,

Dank voor je reactie. Ik had gezworen dat ik idee 1 al had uitgesloten, maar dat blijkt toch het geval te zijn. Het probleem zat hem dus vooral tussen het scherm en de stoel. Ik vond het al zo gek.

Allen dank voor de hulp!

Mvg, Thomas

2 likes

Haha! :rofl: :stuck_out_tongue_winking_eye:

1 like