Teveel wilde planten aanwezig

[gerardnienhuis]

Als ik bij het interne geoportaal zoek naar Wilde Planten dan zie ik 21 keer dezelfde naam in de lijst. wat is hier aan de hand? harvestfout, of zit die info inderdaad zo in het Geoportaal. De metadata lijkt ook allemaal gelijk. Of toch softwarefout?

zie: Wilde planten in de provincie Overijssel, zie bijvoorbeeld

http://acc-metadata.geodataoverijssel.nl/metadata/dataset/607b9eeb-ca9b-4b7c-9538-21b43a652074.xml

[gerardnienhuis]

gecontroleerd: bij Overijssel lijkt maar 1 xml van deze info beschikbaar, waarom er dan 21 te zien zijn in het geoportaal is onduidelijk

[SandroNeumann]

Er zijn in de geo-publisher 21 datasets aan het bronbestand gekoppeld: http://acc-admin.geodataoverijssel.nl/datasources?q=wilde

[gerardnienhuis]

lijkt me een fout van een beheerder van geopublisher, of zou dit een logische noodzaak hebben gehad? Of geeft dit een fout in geopublisher aan?

[gerardnienhuis]

Hoe is dit te voorkomen? Ik wil maar 1 keer een bestand zien in het geoportaal

Nu word het onnodig ingewikkeld voor gebruikers en beheerders

Verstuurd vanaf mijn iPhone

Op 2 jun. 2016 om 16:35 heeft SandroNeumann notifications@github.com<mailto:notifications@github.com> het volgende geschreven:

Er zijn in de geo-publisher 21 datasets aan het bronbestand gekoppeld: http://acc-admin.geodataoverijssel.nl/datasources?q=wilde

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/IDgis/geoportaal-test/issues/202#issuecomment-223311012, or mute the threadhttps://github.com/notifications/unsubscribe/AIlphHWE7Y9d8k8uGqth1Y4lrQm6jYy-ks5qHuobgaJpZM4IsaWc.

---

Het is mogelijk dat er tijdens het transport van dit bericht fouten zijn ontstaan zodat het bericht onjuist is overgekomen. Hiervoor kunnen wij geen aansprakelijkheid erkennen. Indien er sprake is van een besluit zal de vastgestelde versie per post aan u worden toegezonden. Indien er sprake is van overige mededelingen adviseren wij u om bij twijfel over de juistheid of volledigheid contact met ons op te nemen.

---

[SandroNeumann]

Het is de acceptatie omgeving, dus het zal een testcase geweest zijn. Er is geen reden om meerdere datasets te maken die precies hetzelfde zijn.

[gerardnienhuis]

Ik ga proberen binnenkort meerdere varianten hiervan in de publicatieomgeving uit te testen. Vooralsnog lijkt het er dus op, dat het waarschijnlijk geen bug is. Ik wil dat wel graag nog controleren.

Van: SandroNeumann [mailto:notifications@github.com] Verzonden: vrijdag 3 juni 2016 9:16 Aan: IDgis/geoportaal-test CC: Nienhuis, G (Gerard); Author Onderwerp: Re: [IDgis/geoportaal-test] Teveel wilde planten aanwezig (#202)

Het is de acceptatie omgeving, dus het zal een testcase geweest zijn. Er is geen reden om meerdere datasets te maken die precies hetzelfde zijn.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/IDgis/geoportaal-test/issues/202#issuecomment-223508031, or mute the threadhttps://github.com/notifications/unsubscribe/AIlphEW-uGW3Du1i81PeumpAfc6PlhpWks5qH9S8gaJpZM4IsaWc.

---

Het is mogelijk dat er tijdens het transport van dit bericht fouten zijn ontstaan zodat het bericht onjuist is overgekomen. Hiervoor kunnen wij geen aansprakelijkheid erkennen. Indien er sprake is van een besluit zal de vastgestelde versie per post aan u worden toegezonden. Indien er sprake is van overige mededelingen adviseren wij u om bij twijfel over de juistheid of volledigheid contact met ons op te nemen.

---

[gerardnienhuis]

in de metadata blijkt dat ook de service niet zichtbaar is. van de dataset Wilde planten zijn selecties gemaakt, en daar blijkt het fout te gaan. In de pub. omgeving is de naam wel correct toegevoegd, en die is ook in de B4 services te zien: helaas is in het geoportaal niet de naam van de laag meegenomen. Blijkt dus inderdaad bug: de naam Korenbloem is wel in pub. omgeving gegeven, staat ook in service, maar niet goed geoportaal naam overgenomen... zie ook plaatje hieronder: zwanenbloem ontbreekt in geoportaal, maar is wel zichtbaar bij de betreffende service

[gerardnienhuis]

[gerardnienhuis]

lijkt te maken te hebben met ontbrekende functionaliteit in pub. omgeving, zie #231

[gerardnienhuis]

bij controle extern geoportaal (productieversie 1.0) viel mij op dat ook andere bestanden er dubbel in staan. Ik verwacht dat dit door hetzelfde probleem als bij de "wilde planten" wordt veroorzaakt.

zie bijvoorbeeld:

zoek naar natuurbeheerplan of Zeer kwetsbare gebieden volgens Wet ammoniak en veehouderij

[SandroNeumann]

lijkt sterk op #231

[copierrj]

Ter informatie: het hebben van meerdere datasets bij een enkel brondataset komt dit moment (uitsluitend) voor bij de volgende brondatasets:

Hulpverleningsregio's in Overijssel (4x) Zeer kwetsbare gebieden volgens Wet ammoniak en veehouderij (2x) Natuurbeheerplan Overijssel 2016 (7x) Wilde planten in de provincie Overijssel (21x)

[gerardnienhuis]

Voorstel om dubbele namen in Geoportaal op te lossen:

1) naam van laag uit publicatieomgeving doorgeven naar Geoportaal 2) controle in publicatieomgeving dat laagnaam altijd andere naam heeft als originele naam van dataset

[gerardnienhuis]

Dit verschijnsel kan nog steeds optreden. Voorlopig opgelost door geen selecties uit te voeren in publicatieomgeving. Deze worden door beheerders van te voren gedaan. Selecties worden als afzonderlijke geodatasets aangeboden, zodat dit probleem niet kan optreden. Moet t.z.t. wel verder opgelost maar is hierdoor minder urgent nu.

[gerardnienhuis]

vraag aan @SandroNeumann : is de impact nog steeds "hoog" bij dit issue? Of is er door veranderingen van inzicht of techniek nu minder tijd nodig om dit probleem op te lossen? Ik vraag dit omdat we er toch zo nu en dan weer tegenaan lopen, de afgelopen tijd.

[SandroNeumann]

Ik zal het hier met Reijer Copier (vrijdag) over hebben. Hij heeft dit destijds geanalyseerd en als 'impact hoog' gelabeld.

[SandroNeumann]

Een refresh waar het hier om gaat:

We gebruiken de metadata die van jullie kant uit GeoSticker komt. We passen vervolgens in onze metadata generator wat zaken aan in deze metadata, zoals de metadata 2.0 transformatie en wms/wfs url's wanneer dat van toepassing is. Wat we echter niet aanpassen is de bestandsnaam en de samenvatting. Deze worden door het Geoportaal geharvest en uit de metadata gelezen, waardoor je een herhaling ziet omdat deze oorspronkelijk uit de brondataset komt.

Wat we zouden kunnen doen is de bestandsnaam in de metadata overschrijven met de naam van de dataset in de GeoPublisher.

Zie:

Dit betekent echter dat een aanpassing van de bestandsnaam in de metadata in GeoSticker niet direct tot gevolg heeft dat deze in het Geoportaal ook aangepast wordt. Daarvoor moet dan eerst ook de naam van de dataset in de GeoPublisher aangepast worden.

Het betekent ook dat de samenvatting nog altijd hetzelfde blijft. De vraag is of dat wenselijk is. We zouden een optioneel veld 'samenvatting' in het bovenstaande formulier kunnen introduceren. Als de beheerder deze niet invult wordt de samenatting uit de brondataset overgenomen. Als deze wel ingevuld is wordt deze samenvatting in de metadata geschreven. Ook hier geldt hetzelfde als bij de bestandsnaam: mocht de samenvatting in GeoSticker aangepast worden werkt het niet automatisch door in het Geoportaal, want het moet dan eerst ook bij de dataset in de GeoPublisher aangepast worden.

[gerardnienhuis]

alleen uitvoeren als er meer dan 1 dataset bij een brondatasets is: dus bijvoorbeeld bij meerdere selecties.

dan naam en samenvatting laten veranderen (dus wat ingevuld wordt door beheerder publicatieomgeving). Maar als samenvatting leeg is (dus als beheerder pub omgeving dit is vergeten) dan samenvatting brondataset gebruiken.

[gerardnienhuis]

merk op: namen moeten uniek zijn, wordt nu al door pub omgeving afgevangen. maar ook samenvattingen moeten uniek zijn: dat moet verplicht worden

[gerardnienhuis]

let op: als er een filtering wordt toegepast, dan krijg je bij opslaan de vraag of je ook het originele bestand wilt opslaan (dus het ongefilterde bestand). Is het antwoord ja, dan wordt een kopie van het originele bestand gemaakt .

[gerardnienhuis]

dus: dataset zonder filtering blijft dan de naam en samenvatting houden zoals door de beheerder van geosticker is aangeleverd. De beheerder van de publicatieomgeving krijgt bij filteren 1 vraag extra, namelijk of er een extra dataset aangemaakt moet worden zonder filtering? men kan dan ja of nee antwoorden. Die extra (dus de originele) dataset moet er alleen komen als die nog niet bestaat.

[gerardnienhuis]

als het antwoord nee is, dan wordt de extra dataset niet gemaakt

[gerardnienhuis]

als de extra dataset al bestaat, dan mag je gewoon filtering toevoegen. Je krijgt dus die vraag alleen bij de eerste keer van filtering

[SandroNeumann]

Extra notificatie voor bronmetadata toevoegen: samenvatting van bronmetadata met gefilterde datasets is aangepast.

[SandroNeumann]

Hetzelfde geldt voor de naam in de bronmetadata.

Ook hier alleen maar notificatie voor bronmetadata waar gefilterde datasets bij gemaakt zijn.

[SandroNeumann]

Alleen als er een filter is toegevoegd kan een samenvatting worden toegevoegd en dan is de samenvatting ook verplicht.

[SandroNeumann]

De samenvatting bij gefilterde datasets moet uniek zijn.

[SandroNeumann]

Oplossingsrichting:

In de webdav van datasets filteren we de datasets met filter uit, zodat deze niet naar het Geoportaal en NGR doorgestuurd wordt. Overijssel zal moeten controleren dat er wel een dataset zonder filter obv het bronmetadata bestand gemaakt is, zodat deze wel beschikbaar is in NGR en het Geoportaal.

Activiteiten:

• in webdav datasets met filter niet opnemen

[gerardnienhuis]

Voor de duidelijkheid:

De wens is dus dat wij wel de originele metadata in geoportaal zien, zowel in archief, intern, extern, NGR en rapportages) Maar we willen niet de metadata van de gefilterde datasets zien (niet in archief, intern, extern, NGR en ook niet in rapportages)

@SandroNeumann : ik neem aan dat bovenstaande beschrijving klopt?

[SandroNeumann]

Dat is correct.

[gerardnienhuis]

Dit is niet volledig opgelost: gezocht naar B4.NNN_ONW_polygon levert 2 dezelfde regels metadata op. Dat gaat ook bij B4.wav_polygon.

nb: deze metadatasets gevonden door te zoeken in rapport geodata naar "gekoppelde datasets > 1".

Bij B4.Natuurbeheerplan2017_polygon gaat het echter wel weer goed, terwijl hier nog meer datasets gekoppeld zijn volgens het rapport.

[SandroNeumann]

@gerardnienhuis

Van je voorbeelden is er nog maar 1 dataset actueel en dat is B4.wav_polygon.

Wat daar aan de hand is dat er twee maal van dezelfde brondata een dataset is aangemaakt zonder filter. Wij sturen alleen datasets door wanneer er geen filter aan hangt. Maar als je twee maal een dataset aanmaakt zonder filter krijg je alsnog een verdubbeling. Het is dan exact dezelfde dataset. Ik zie zelf geen reden waarom je zoiets zou willen dus volgens mij moet je dan aan de bel trekken bij de beheerder van de publisher.

[SandroNeumann]

Na overleg met Gerard blijkt dit vervuiling van de data van de testomgeving te zijn. Het issue kan gesloten worden.

[gerardnienhuis]

voor zekerheid gaat André binnenkort nog een laatste controle uitvoeren

[gerardnienhuis]

het lijkt nog niet goed in de rapportage te komen, ik heb mail met vragen gestuurd.

[SandroNeumann]

Ik heb email gestuurd als antwoord.

[gerardnienhuis]

probleem lijkt opgelost, issue kan gesloten

[gerardnienhuis]

probleem wat nu ontstaat is dat de metadata niet altijd correct is: het gefilterde bestand kan bijvoorbeeld openbaar gezet zijn (downloadable in metadata) maar het bronbestand is dat niet. Nu staat het er echter wel zo in, als je het geoportaal bekijkt. Is het mogelijk om zowel het gefilterde als het oorspronkelijke bestand van metadata te voorzien?