Work out WMS layer management screen

[lexvand]

In order to make wms layer management screens, a new wmslayer endpoint has to be added to api/v4.

User requirements

• Organisation
• Shared with organisation
• Name
• Description
• URL (eg ' https://geoserver9.lizard.net/geoserver/almere/wms/ ') + slug (eg 'Divers_Versh_shapeli')
• Get feature info
  • On/off
  • GetFeatureInfoURL
• Get Legend
  • GetLegendURL (not used in any client yet)
• Zoom level (min / max)
• Options (json field in admin; most users won’t know which attributes can be specified)
  • Transparent: true/false (concerns background color; maybe we should make this True by default)
  • (are there any more options that should be specified explicitly?)

Technical requirements

• wmslayer endpoint in api/v4

• deletion should be allowed

Properties for new wmslayer endpoint for api/v4

from api/v3:

• uuid
  • readonly
  • required
  • GET-format: string
  • POST-format: same
• name
  • read write
  • required
  • GET-format: string
  • POST-format: same
• description
  • read write
  • optional (Yes, but we force people to enter a description in the frontend, like raster management)
    • default: null
  • GET-format: string
  • POST-format: same
• slug
  • read write
  • required
  • GET-format: string
  • POST-format: same
• get_feature_info
  • read write
  • optional
    • default: False
  • GET-format: boolean
  • POST-format: same
• min_zoom
  • read write
  • optional
    • default: null (minimum = 0 entered as standard on the client)
  • GET-format: int
  • POST-format: same
• max_zoom
  • read write
  • optional
    • default: null (maximum = 31 entered as standard on the client)
  • GET-format: int
  • POST-format: same
• url
  • read write
  • required
  • GET-format: string
  • POST-format: same
• tiled
  • read write
  • required
    • default: True
  • GET-format: boolean
  • POST-format: same
• options
  • read write
  • optional
    • default: null
  • Get-format: json
  • POST-format: same
    • Transparent: true/false (concerns background color; maybe we should make this True by default)
    • (are there any more options that should be specified explicitly?)
• legend_url (getLegendUrl not used in any client yet)
  • read write
  • optional
    • default: null
  • GET-format: string
  • POST-format: same
• get_feature_info_url
  • read write
  • optional
    • default: null
  • GET-format: string
  • POST-format: same

new for api/v4:

• Organisation
  • read write
  • required
  • GET-format: string
• Shared with organisation
  • read
  • optional
    • default: null
  • GET-format: list of jsons
    • with url, name and uuid of organisation
  • POST-format: same
• get_legend_info?
  • There is a boolean for the get_feature_info which is used for GeoServer to create an alternative link for rasters. To be consistent with this, it might also be a good idea to add a boolean for get Legend.

[FRNT-281] created by lex.vandolderen

[lexvand]

Lex van Dolderen kan jij de workflow voor dit formulier nog delen?

by 5b03d19111b5d05139269675

[lexvand]

Oh ja, Lex van Dolderen

Had jij nog een lijstje van wensen van de gebruikers wat ze van de wms zouden willen?

by madeleine.vanwinkel

[lexvand]

Madeleine van Winkel See the Epic issue.

by lex.vandolderen

[lexvand]

Tx! ��

by madeleine.vanwinkel

[lexvand]

Als ik het wensenlijstje (zie de epic, https://nelen-schuurmans.atlassian.net/browse/GH-291 ) met de backend vergelijk, valt het volgende op:

api/v4

• er is nog geen wms endpoint in api/v4

api/v3

• wmslayers in api/v3 mist nog een aantal dingen ten opzichte van het lijstje:
  • organisation
  • shared with organisation

Er is al afzonderlijk een url en een slug veld. Lex van Dolderen bedoel je een combinatie van deze 2 velden met URL (e.g. 'https://geoserver9.lizard.net/geoserver/almere/wms/') + slug (e.g. 'Duikers_verv_shapeli') (https://nelen-schuurmans.atlassian.net/browse/GH-291 )?

by madeleine.vanwinkel

[lexvand]

Casper van der Wel

Hey Casper,

There is a wish to make management screens for wms.

You can see the wish list in the description.

Comparing the wishlist with the backend, I notice the following:

api/v4

• there is no wms endpoint yet

api/v3

• wmslayers in api/v3 is missing some properties when compared to the list:
  • organisation
  • shared with organisation

Is it correct if I assume that api/v3 is static, and therefore, if organisation and shared with organisation have to be added, a new wms endpoint has to be made in api/v4?

by madeleine.vanwinkel

[lexvand]

Is it correct if I assume that api/v3 is static, and therefore, if organisation and shared with organisation have to be added, a new wms endpoint has to be made in api/v4?

Yes, we will need to make a new API v4 endpoint for this.

by casper.vanderwel

[lexvand]

Lex van Dolderen

I can already make a start on the wms management screens, but at this point organisation and shared with organisation cannot be added as options yet (we need the backend to implement that in a new api endpoint in api/v4).

The side note is also that currently, api/v3 will have to be used, because there is no api/v4 wms endpoint yet.

by madeleine.vanwinkel

[lexvand]

And the WMS-layers endpoint should become writable right? not read only…

by 5b03d19111b5d05139269675

[lexvand]

What we need is a list of fields, and per field:

• readonly or readwrite
• format (datatype) of the field for GET
• if readwrite: format of the data for POST (mostly, the same as the format for GET)
• if readwrite: required or optional
• if optional: default value (mostly: NULL)

For the rest: should we allow deletion?

We can of course make the list together. API/v3 is a good start point

by casper.vanderwel

[lexvand]

Yes, deletion should be allowed.

by 5b03d19111b5d05139269675

[lexvand]

Madeleine van Winkel The main URL of the WMS service and the layer slug are two attributes that are closely related, but they are separate items in the model. Because of their relation I thought it would be good to combine them in 1 step.

by lex.vandolderen

[lexvand]

Lex van Dolderen

Should all the fields of the user requirements be read write?

by madeleine.vanwinkel

[lexvand]

Lex van Dolderen

I’ve updated the description with what I think should be the requirements for the new wms endpoint.

Could you check whether the read/write / readonly property per wms property is according to the user requirements (and otherwise change them? (Blue in the description.)

by madeleine.vanwinkel

[lexvand]

Lex van Dolderen can you make a ticket: implement Legends loaded from GetLegend url from wms-services in Lizard Portal and Lizard Dashboard and Lizard Atlas?

by 5b03d19111b5d05139269675

[lexvand]

Lex van Dolderen Joeri Verheijden Madeleine van Winkel

Hi,

I checked the list of available fields above.

This makes me assume that:

• The field “tiled” is not needed on the client. ( we decided explicitly)
• The field “supplier” is not needed on the client. (nobody explicitly decided this. Are we sure?)
• The field “acces_modifier” is not needed on the client. (nobody explicitly decided this. Are we sure ? )

Please let me know if my assumptions are correct, so I can proceed with this ticket.

kr Tom

by 5b3b278169812b2ef3f78d91

[lexvand]

Hi,

Lex van Dolderen can you come up with reasons to add supplier. I don’t think it’s needed.

access_modifier is required on the client. A user should be able to make a WMS layer public, private or common.

Sorry for the late reply!

by 5b03d19111b5d05139269675

[lexvand]

Joeri Verheijden Already discussed this with Tom. Only use of supplier would be to enable non-admins to manage layers that they are supplier of. But do we see that happen in any near future?

We have left it out for now. Access_modifier will be included.

by lex.vandolderen

[lexvand]

Ok. It would make it consistent with raster management. Let’s add this feature.

by 5b03d19111b5d05139269675