<div dir="ltr">Thanks Jeff! Should the wiki page be deleted to avoid confusion?<div><br></div><div>I'm interested in what folks think about the Inja templating/includes issues detailed in the Security Considerations -> Template Handling section.</div><div><br></div><div>Regarding the wishlist/tasks:</div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><i><b>task:</b> add ows_contact* information to the landing page (from the associated values set in the mapfile)</i></span></div><div>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...</div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px;font-weight:bold"><br></span></div><div><i><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px;font-weight:bold">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">besides the “/ogcapi” API signature (for features, maps..support), also allow “/features” (to allow developers to only request vector collections),</span></i></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px">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})?</span></font></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px">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.</span></font></div><div><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><i><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">include MapServer logo on landing page</span></i></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">I don't think we want to mess with requiring users to install assets in a web accessible directory. Possible solutions would be:</span></div><div><ol><li><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">base64 encode a version of the logo and include it in the shared header</span></li><li><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">place a few assets on <a href="http://mapserver.org">mapserver.org</a> and reference them there</span></li></ol><i><b>wishlist:</b> <span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">set MapServer favicon for all HTML pages</span></i></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">See last item, I think either option would work here too...</span></div><div><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><i><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">allow other link types for collection </span>item<span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"> (set through mimetype/outputformats in mapfile?)</span></i></div><div>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):</div><div><br></div><div>METADATA</div><div> gml_constants "itemlink1"</div><div> gml_itemlink1_value "<a href="http://foo.com/?id={{">http://foo.com/?id={{</a> attribute }}"</div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"> ...</span></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">END</span></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">Or something along those lines. I don't think automatic link generation is a good idea, users should be explicit.</span></div><div><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><i><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">instead of text links, use a dropdown for types (JSON, HTML, KML, etc.)</span></i></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px">Not sure what you're proposing here...</span></font></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px;font-weight:bold"><br></span></div><div><i><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px;font-weight:bold">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">for the single layer map, include a dropdown to set the default number of features displayed in the map:</span></i></div><div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">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).</span></div><div><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px"><br></span></div><div><i><span style="font-weight:bold;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">wishlist: </span><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:12.8px">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)</span></i></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px">There is no MapServer scale value available - MapServer isn't producing a map. I think we should delete this item... </span></font></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px">--Steve</span></font></div><div><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:12.8px"><br></span></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 26, 2021 at 6:55 AM Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The OGC API draft has now been converted to an RFC: <br>
<a href="https://mapserver.org/development/rfc/ms-rfc-134.html" rel="noreferrer" target="_blank">https://mapserver.org/development/rfc/ms-rfc-134.html</a><br>
<br>
(some might prefer to follow the 'Current Status' section: <br>
<a href="https://mapserver.org/development/rfc/ms-rfc-134.html#current-status" rel="noreferrer" target="_blank">https://mapserver.org/development/rfc/ms-rfc-134.html#current-status</a><br>
<br>
-jeff<br>
<br>
<br>
<br>
On 2021-05-23 7:45 a.m., Jeff McKenna wrote:<br>
> Hi Tom,<br>
> <br>
> I've updated the status wording in the draft to:<br>
> <br>
> - **wishlist:** besides the "/ogcapi" API signature (for features, <br>
> maps..support), also allow "/features" (to allow developers to only <br>
> request vector collections), for example:<br>
> ```<br>
> <a href="http://127.0.0.1/cgi-bin/mapserv.exe/demo-ogcapi/features" rel="noreferrer" target="_blank">http://127.0.0.1/cgi-bin/mapserv.exe/demo-ogcapi/features</a><br>
> ```<br>
> (Note that is how the GeoServer implementation works, when I was <br>
> testing other implementations, and as a user this made sense)<br>
> <br>
> <br>
> -jeff<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On 2021-05-22 9:59 a.m., Tom Kralidis wrote:<br>
>> Hi all:<br>
>><br>
>> Great work Steve/Jeff.<br>
>><br>
>> Regarding the task:<br>
>><br>
>> - *task:* change "ogcapi" API signature for Features support, to <br>
>> "features", for example:<br>
>><br>
>> I would suggest we keep to ogcapi. The OGC APIs follow the same <br>
>> workflow for<br>
>> the following endpoints:<br>
>><br>
>> - /<br>
>> - /conformance<br>
>> - /collections<br>
>> - /collections/{collectionId}<br>
>><br>
>> This is by design so we don't have to implement specifically foreach <br>
>> OGC API<br>
>> standard per se. So imagine an OGC API server is a deployment of 1..n<br>
>> collections (maps, features, coverages, styles, etc.) from a single <br>
>> endpoint.<br>
>><br>
>> ..Tom<br>
>><br>
>><br>
>><br>
>> On Fri, May 21, 2021 at 5:12 PM Jeff McKenna <br>
>> <<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank">jmckenna@gatewaygeomatics.com</a> <mailto:<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank">jmckenna@gatewaygeomatics.com</a>>> <br>
>> wrote:<br>
>><br>
>> Hi Steve, all,<br>
>><br>
>> I've compiled a small table for what is the status, and a list of<br>
>> issues<br>
>> and tasks, at<br>
>> <br>
>> <a href="https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status" rel="noreferrer" target="_blank">https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status</a> <br>
>><br>
>> <br>
>> <<a href="https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status" rel="noreferrer" target="_blank">https://github.com/mapserver/mapserver/wiki/OGC-API-RFC-Draft#current-status</a>> <br>
>><br>
>><br>
>> I'm sure it could have been its own page, or even pasted here <br>
>> instead,<br>
>> but at least it is somewhere and we can keep it updated now. (edits<br>
>> welcomed!)<br>
>><br>
>> -jeff<br>
>><br>
>><br>
>><br>
>> > On 2021-05-10 11:41 p.m., Steve Lime wrote:<br>
>> > > Hi all: I have the OGC API initial support in pretty good<br>
>> shape<br>
>> > so I'd<br>
>> > > love to get some review if folks have time. The RFC draft<br>
>> has be has<br>
>> > > been updated and lives at:<br>
>> > ><br>
>> > > *<br>
>> <a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a><br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a>><br>
>> > <br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a><br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a>>><br>
>> > ><br>
>> > <br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a><br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a>><br>
>> > <br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a><br>
>> <<a href="https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/wiki/OGC-API-RFC-Draft</a>>>><br>
>> > ><br>
>> > > and the code is at:<br>
>> > ><br>
>> > > * <a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a><br>
>> <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a>><br>
>> > <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a><br>
>> <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a>>><br>
>> > > <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a><br>
>> <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a>><br>
>> > <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a><br>
>> <<a href="https://github.com/MapServer/MapServer/pull/6180" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/pull/6180</a>>>><br>
>> > ><br>
>> > > Still working on the openapi response and formalizing<br>
>> tests. I'm<br>
>> > happy<br>
>> > > to assist with some setup if someone would like to try it.<br>
>> > ><br>
>> > > --Steve<br>
>> ><br>
> <br>
-- <br>
Jeff McKenna<br>
GatewayGeo: Developers of MS4W, MapServer Consulting and Training<br>
co-founder of FOSS4G<br>
<a href="http://gatewaygeo.com/" rel="noreferrer" target="_blank">http://gatewaygeo.com/</a><br>
_______________________________________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</blockquote></div>