dan lijkt het beeld niet overeen te komen met de terreinsituatie. Het DSM/DTM beeld zou ongeveer 100m N en 100 m W moeten verschoven worden. Doe ik iets fout in de URL? Zowel CRS als RESPONSE_CRS staan ingesteld op EPSG:31370.
Hier zie je het gedownloade beeld (donkerder gekleurd vierkant) met in de achtergrond dezelfde DSM laag toegevoegd in QGIS via QGIS-WCS connectie. De rode lijntjes geven de verschuiving. De weergave in QGIS is de juiste.
Mijn vraag is dus wat het verschil veroorzaakt tussen enerzijds de download via URL en anderzijds de weergave in QGIS.
We kunnen dit reproduceren en zoeken zo spoedig mogelijk naar de oorzaak / oplossing. Je kan eventueel de data opvragen in ETRS89 (EPSG:4258) of WGS84 (EPSG:4326). De data wordt dan correct gepositioneerd
Bedankt om hiernaar te kijken. Ik kan bevestigen dat EPSG:4258 gebruiken werkt. Deze EPSG moet dan wel doorgegeven worden aan zowel CRS als RESPONSE_CRS (of RESPONSE_CRS weglaten, dan krijgt dit de waarde van CRS als default) en de bbox coördinaten moeten dan ook in EPSG:4258.
Ik vermoed dat de WCS versie 1.0.0 transformatie naar EPSG:31370 gewoonweg (nog) niet ondersteund afgaand op info in DescribeCoverage.
We hebben het probleem verder onderzocht en jammer genoeg kunnen we dit momenteel niet verhelpen. In tegenstelling met de wms-services op deze dataset loopt er iets fout bij de transformatie naar het Lambert 72 coördinatensysteem. Om dit verder te onderzoeken en op te lossen nemen we contact op met onze softwareleverancier.
De data achter deze service staat in ETRS89, zolang dit coördinatensysteem gebruikt wordt en de transformatie aan client-zijde correct uitgevoerd wordt zou de combinatie met data in het Lambert72 of een ander coördinatensysteem goed moeten gaan.
We nemen terug contact met u op zodra de data via deze WCS ook in het Lambert 72 coördinatenstelsel bruikbaar is, het probleem verholpen is.
Bedankt om dit verder te bekijken. Heeft versie 2.0.1 van de WCS service hetzelfde probleem? Ik kan het niet zelf controleren omdat de download met versie 2.0.1 een .mht bestand is waarin een base64 (?) gecodeerde .tif zit. Ik weet echter niet hoe ik die .tif daar uit moet halen. Het zou interessant zijn als de 2.0.1 versie ook toelaat om rechtstreeks een .tif bestand te downloaden (maar dat is een ander issue).
Wanneer je een beeld opvraag met versie 2.0.1 vertoont dit hetzelfde probleem. Het probleem zit in de transformatie aan de server-kant.
De response die u krijgt bij het gebruik van versie 2.0.1 is een multipart-response. De delen van de multipart-response zijn gescheiden door “–wcs”.
Het eerste deel van de response betreft een xml-document met wat beschrijvende informatie.
Het tweede deel bevat inderdaad het tif-bestand.
Om het beeld er manueel uit te halen kan je gebruik maken van bijvoorbeeld notepad++. Dit door het bestand hierin te openen, de xml-informatie, de “Content-” tags van het tif-deel alsook op het einde de lijn met “–wcs–”, te wissen. Wanneer je het document dan opslaat en het naar .tif hernoemd (bestandsextensie tif) dan heb je een geotiff.
