Lijkt weer een migratie van GeoServer naar MapServer te betreffen, gezien de foutmeldingen. Of @Jeroen_D draait de migratie terug, of voegt een stukje code aan z’n MAP-files toe, opdat MapServer ook JSON kan uitspugen, zoals bijvoorbeeld bij mapserver/header.inc at master · Amsterdam/mapserver · GitHub.
Graag @Jeroen_D, terugdraaien (hoezeer ik ook fan ben van MapServer). GeoServer ondersteunt natuurlijk een hele reeks WFS-outputformaten: GML in verschillende (sub)versies, CSV, t/m zipped Shapefiles. Tenminste als die “aan” stonden.
Wat ik ook in bijv de KadViewer fout zie gaan is dat de generieke WMS/WFS “ows” URL een 404 oplevert:
@Just_OSGeo, @emacgillavry, @rein
We hebben deze uitrol voor nu teruggezet naar geoserver.
Hierbij valt wel de opmerking te maken dat niet via de GetCapabilities gekeken werd welke outputFormats beschikbaar waren/zijn. Dat is een risico wanneer de betreffende hand-shake niet wordt gedaan vanuit de client, maar rechtstreeks op het endpoint.
Dit is geen pluspunt voor ons, vanuit een beheer perspectief gezien.
Dat meerdere wegen naar Rome leiden is mooi, maar die moeten wel allemaal onderhouden kunnen worden.
We willen m.b.t. outputFormats naar een gecontroleerde situatie waarbij het helder is wat we naar buiten communiceren en niet aan de grillen van bijvoorbeeld een Geoserver zijn overgelaten.
Tevens de stabiliteit van Geoserver is een groot issue voor ons.
Andere redenen voor migratie naar mapserver zijn o.a. dat met de huidige INSPIRE regels geoserver op een aantal punten niet meer voldoet (m.b.t. StoredQueries).
Dat dit voor een aantal van onze services nu voor problemen heeft gezorgd is spijtig, dit in combinatie met de INSPIRE deadline van 15 maart.
We willen hier op korte termijn bredere over gaan communiceren.
Idee die we daarbij hebben zijn o.a.:
De service GetCapabilities gaf overigens ook aan dat het outputFormat JSON toegestaan was (ook toen alles gemigreerd was naar MapServer). Dit had ik ook gecontroleerd.
Wat handig zou zijn als we ons ergens op een mailinglist/slack etc zouden kunnen abonneren (eventueel per service) zodat we onoverkoombare breaking changes tijdig zien aankomen. Dan hebben jullie ook een beter beeld wie en hoe de services gebruikt worden.
Mooi dat het is opgelost, excuses voor de issues! We gaan intern kijken naar een (zie ook opmerking van Wouter) migratiepad en zullen daarbij op tijd communiceren.
Mee eens: WFS interworking is op zich al zo vol valkuilen dat die rits output formaten het alleen maar lastiger maken. Was meer dat ik verwacht dat er links en rechts apps zullen “omvallen”.
Mogelijk is de situatie nu anders, maar aantal jaar geleden vond ik zoveel interworking problemen tussen clients als OpenLayers en willekeurige WFS servers (en tussen GeoServer versies!) dat ik op “lowest common denominator” ben gaan zitten: WFS 1.0.0 met GML 2 (GML3 was (is?) helemaal een ‘can of worms’). We willen tenslotte wat platte records met attributen en geometrie, semantisch maakt dit nl, behalve voor complex features/app-schema/INSPIRE, niet uit.
GeoServer en MapServer gedragen zich qua WFS net iets anders, GeoServer lijkt daarbij wat meer “permissive” (MapServer lijkt strenger), maar kan soms ook configuratie-instelling zijn.
Ik zie subtiele verschillen nu bij Natura2000 (vast MapServer) vs inspireadressen (GeoServer):
Dat is zeker ook niet onze intensie geweest. (de focus lag misschien te veel op de INSPIRE validatie)
En ook dit maakt het weer duidelijk dat het niet kennen van onze afnemers het allemaal een stuk complexer maakt. Wie had gedacht dat de inspireaddressen (1x per maand ververst) gebruikt werden ipv de bag (dagelijks ververst)
Vandaar dat we graag naar geversioneerde URL’s gaan, zoals ook bij de locatieserver.
Maar omdat te kunnen realiseren moet er niet alleen qua techniek maar ook op business level nog veel worden afgestemd. (de eeuwige vraag: wie gaat 't betalen…)
Ik benijd jullie niet : laten we hopen dat WFS versie 3 (REST-based) minder hoofdbrekens gaat opleveren…
inspireaddressen : ging ervan uit dat dit de enige dataset/laag was die volledige adressen (nu ja, t/m woonplaats) bevat. bag als in https://geodata.nationaalgeoregister.nl/bag/wfs kan dit toch niet? Of is er nog een bag-WFS (laag) met volledige adressen, die ik niet ken? bagviewer WFS, notabene nog voor PDOK ontwikkeld, maar die is toch uitgefaseerd?
: laten we hopen dat WFS versie 3 (REST-based) minder hoofdbrekens gaat opleveren…