[mapserver-dev] OGC API Review Requested
Steve Lime
sdlime at gmail.com
Wed Jun 30 07:09:05 PDT 2021
Thanks Jeff! Should the wiki page be deleted to avoid confusion?
I'm interested in what folks think about the Inja templating/includes
issues detailed in the Security Considerations -> Template Handling section.
Regarding the wishlist/tasks:
*task: add ows_contact* information to the landing page (from the
associated values set in the mapfile)*
I don't think contact information is part of the core specification is it?
I see pygeoapi does support it but is there a standard approach...
*wishlist: besides the “/ogcapi” API signature (for features,
maps..support), also allow “/features” (to allow developers to only request
vector collections),*
Need to make a decision on this. Curious what Tom's take is. If there is no
overlap in endpoint naming between the Features, Maps, etc...
specifications (besides API common) then perhaps it's not necessary and we
can just stick to the single signature. It gets messy otherwise. I mean,
let's say we eventually support Features and Maps and the signature is
"features" - should that limit the API paths to common + the couple of
Features endpoints (/items and /items/{itemId})?
Right now in terms of enabling OGC API it's all or nothing but that's just
because we're concentrating on Features. We could add the ability to only
enable API endpoints associated with a specific specification (e.g.
Features, Maps, Coverages) via metadata.
*wishlist: include MapServer logo on landing page*
I don't think we want to mess with requiring users to install assets in a
web accessible directory. Possible solutions would be:
1. base64 encode a version of the logo and include it in the shared
header
2. place a few assets on mapserver.org and reference them there
*wishlist: set MapServer favicon for all HTML pages*
See last item, I think either option would work here too...
*wishlist: allow other link types for collection item (set through
mimetype/outputformats in mapfile?)*
Not exactly sure what you're proposing here. Can you provide an example? I
do think it's worth considering mechanisms to create item/feature specific
links that are derived from the data associated with the feature. One idea
would be to treat gml_constants as Inja templates, so for example (I think
this is right):
METADATA
gml_constants "itemlink1"
gml_itemlink1_value "http://foo.com/?id={{ attribute }}"
...
END
Or something along those lines. I don't think automatic link generation is
a good idea, users should be explicit.
*wishlist: instead of text links, use a dropdown for types (JSON, HTML,
KML, etc.)*
Not sure what you're proposing here...
*wishlist: for the single layer map, include a dropdown to set the default
number of features displayed in the map:*
I assume you're talking about the /collections/{collectionId}/items
endpoint. Yes, we can add a control (similar to pygeoapi), as well as
controls to allow stepping through the results, assuming paging is
necessary. I don't know if it's worth adding a layer-level map. I suppose
we can and make it toggleable using tags (like debug info is).
*wishlist: for the single layer map, display the current MapServer scale
value below the map (as user zooms in, update the scale with the CGI
[scale] value)*
There is no MapServer scale value available - MapServer isn't producing a
map. I think we should delete this item...
--Steve
On Sat, Jun 26, 2021 at 6:55 AM Jeff McKenna <jmckenna at gatewaygeomatics.com>
wrote:
> The OGC API draft has now been converted to an RFC:
> https://mapserver.org/development/rfc/ms-rfc-134.html
>
> (some might prefer to follow the 'Current Status' section:
> https://mapserver.org/development/rfc/ms-rfc-134.html#current-status
>
> -jeff
>
>
>
> On 2021-05-23 7:45 a.m., Jeff McKenna wrote:
> > Hi Tom,
> >
> > I've updated the status wording in the draft to:
> >
> > - **wishlist:** besides the "/ogcapi" API signature (for features,
> > maps..support), also allow "/features" (to allow developers to only
> > request vector collections), for example:
> > ```
> > http://127.0.0.1/cgi-bin/mapserv.exe/demo-ogcapi/features
> > ```
> > (Note that is how the GeoServer implementation works, when I was
> > testing other implementations, and as a user this made sense)
> >
> >
> > -jeff
> >
> >
> >
> >
> >
> > On 2021-05-22 9:59 a.m., Tom Kralidis wrote:
> >> Hi all:
> >>
> >> Great work Steve/Jeff.
> >>
> >> Regarding the task:
> >>
> >> - *task:* change "ogcapi" API signature for Features support, to
> >> "features", for example:
> >>
> >> I would suggest we keep to ogcapi. The OGC APIs follow the same
> >> workflow for
> >> the following endpoints:
> >>
> >> - /
> >> - /conformance
> >> - /collections
> >> - /collections/{collectionId}
> >>
> >> This is by design so we don't have to implement specifically foreach
> >> OGC API
> >> standard per se. So imagine an OGC API server is a deployment of 1..n
> >> collections (maps, features, coverages, styles, etc.) from a single
> >> endpoint.
> >>
> >> ..Tom
> >>
> >>
> >>
> >> On Fri, May 21, 2021 at 5:12 PM Jeff McKenna
> >> <jmckenna at gatewaygeomatics.com <mailto:jmckenna at gatewaygeomatics.com>>
> >> wrote:
> >>
> >> Hi Steve, all,
> >>
> >> I've compiled a small table for what is the status, and a list of
> >> issues
> >> and tasks, at
> >>
> >>
> https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status
> >>
> >>
> >> <
> https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status>
>
> >>
> >>
> >> I'm sure it could have been its own page, or even pasted here
> >> instead,
> >> but at least it is somewhere and we can keep it updated now. (edits
> >> welcomed!)
> >>
> >> -jeff
> >>
> >>
> >>
> >> > On 2021-05-10 11:41 p.m., Steve Lime wrote:
> >> > > Hi all: I have the OGC API initial support in pretty good
> >> shape
> >> > so I'd
> >> > > love to get some review if folks have time. The RFC draft
> >> has be has
> >> > > been updated and lives at:
> >> > >
> >> > > *
> >> https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft>
> >> >
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft>>
> >> > >
> >> >
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft>
> >> >
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft
> >> <https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft>>>
> >> > >
> >> > > and the code is at:
> >> > >
> >> > > * https://github.com/MapServer/MapServer/pull/6180
> >> <https://github.com/MapServer/MapServer/pull/6180>
> >> > <https://github.com/MapServer/MapServer/pull/6180
> >> <https://github.com/MapServer/MapServer/pull/6180>>
> >> > > <https://github.com/MapServer/MapServer/pull/6180
> >> <https://github.com/MapServer/MapServer/pull/6180>
> >> > <https://github.com/MapServer/MapServer/pull/6180
> >> <https://github.com/MapServer/MapServer/pull/6180>>>
> >> > >
> >> > > Still working on the openapi response and formalizing
> >> tests. I'm
> >> > happy
> >> > > to assist with some setup if someone would like to try it.
> >> > >
> >> > > --Steve
> >> >
> >
> --
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20210630/7777e733/attachment-0001.html>
More information about the mapserver-dev
mailing list