Thanks all for the votes and feedback. I'm not sure why I went with the ?mode=config&f=json approach - using the URL path would be a better fit, as I'm trying to follow the OGC API approach as much as possible. Allowing Mapfile references in the index was added in [1].
Daniel - I agree "config" could be confusing, and may be better used for working with the CONFIG directly. I'm now no longer that keen on "homepage" either! Maybe "index" would be a better fit, similar to the root of a website defaulting to index.html. Alternatively, I've just been testing out allowing the homepage/index at the root of MapServer, if the MS_HOMEPAGE_TEMPLATE_DIRECTORY is set. The index would then be returned with an empty URL such as http://localhost/mapserver/. This would also avoid returning the "loadParams(): Web application error. No query information to decode. QUERY_STRING is set, but empty. " message. [1] https://github.com/MapServer/MapServer/pull/6862 -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika@mastodon.social On Tue, Mar 11, 2025, at 5:46 PM, Lime, Steve D (MNIT) via MapServer-dev wrote: > The path after the binary name is available to you through an environment > variable (PATH_INFO) as part of normal web server processing. We leverage > that for OGC API support. In this case, you’d just look at the first > component of the PATH_INFO and see if it matches your keyword (e.g. homepage) > and then process accordingly (if enabled). Otherwise the first component of > PATH_INFO is interpreted as the mapfile (more typically the mapfile alias) – > Seth added that support in 8.2 (I think). > > *From:* Richard Greenwood <richard.greenw...@gmail.com> > *Sent:* Tuesday, March 11, 2025 11:35 AM > *To:* Lime, Steve D (MNIT) <steve.l...@state.mn.us> > *Cc:* Daniel Morissette <dmorisse...@mapgears.com>; > mapserver-dev@lists.osgeo.org > *Subject:* Re: [MapServer-dev] RFC-140 - MapServer Homepage > > > On Tue, Mar 11, 2025 at 8:47 AM Lime, Steve D (MNIT) via MapServer-dev > <mapserver-dev@lists.osgeo.org> wrote: >> One idea might be to support a more restful URL, e.g. >> https://myhost.com/cgi-bin/mapserv/homepage (or /home or /index or ?) >> instead of using a parameter-based approach. Maybe that endpoint name could >> be configurable via the config file – and that could also enable the >> functionality. > > Steve, correct me if I'm wrong, but that seems like it's getting into the > realm of the web server. Like how is the mapserv binary to know that it > should look for, and process, stuff after the "/"? What happens for example > with "cgi-bin/mapserv.fcgi/homepage"? Does Apache know that I want to run the > mapserv binary in fcgi mode and also know to pass the "homepage" part to the > binary as a parameter? I like the idea of a restful syntax but I can't get my > head around the implementation. > > Rich > >> >> *From:* MapServer-dev <mapserver-dev-boun...@lists.osgeo.org> *On Behalf Of >> *Daniel Morissette via MapServer-dev >> *Sent:* Monday, March 10, 2025 4:58 PM >> *To:* mapserver-dev@lists.osgeo.org >> *Subject:* Re: [MapServer-dev] RFC-140 - MapServer Homepage >> >> Hi everyone, >> >> Sorry for being late with my feedback. I like the RFC overall, but was >> wondering if we could find a better trigger than mode=config for this >> feature. My first reaction when I saw mode=config was that this mode could >> be used to deal with the actual config settings in the future if we ever >> want to go there so using mode=config today for this homepage feature could >> limit our future options. That being said, I couldn't find any good names >> other than mode=homepage to match the MS_HOMEPAGE_TEMPLATE_DIRECTORY >> variable that controls it. >> >> I can live with mode=config if we have no better option and am +1 with the >> RFC otherwise. >> >> Daniel >> >> >> >> On 2025-03-09 11:57, Seth G via MapServer-dev wrote: >>> Hi all, >>> >>> I've added in the feedback from the comments above to RFC 140 [1], see diff >>> of changes at [2]. >>> I'd like to now formally propose to adopt this RFC, starting with my +1. >>> >>> Seth >>> >>> [1] https://mapserver.org/development/rfc/ms-rfc-140.html >>> [2] https://github.com/MapServer/MapServer-documentation/pull/1000/files >>> >>> -- >>> web:https://geographika.net & https://mapserverstudio.net >>> mastodon: @geographika@mastodon.social >>> >>> On Wed, Jan 22, 2025, at 4:40 PM, Tom Kralidis wrote: >>>> Thanks Seth. >>>> >>>> RE: service-meta: I would still keep to the link conventions (proper media >>>> type for "type", we could add a custom "service-type=WMS" property), and >>>> include an href as well. >>>> >>>> ..Tom >>>> >>>> On Wed, Jan 22, 2025 at 10:27 AM Seth G <se...@geographika.co.uk> wrote: >>>>> >>>>> Thanks Tom - that pygeoapi pull request is good timing! >>>>> >>>>> After reviewing and reading some of the associated documents, I'm >>>>> planning to update the RFC with the notes below. >>>>> >>>>> pygeoapi has implemented a JSON service for their homepage at [1] (pull >>>>> request at [2]. >>>>> This implements the api-catalog, a draft IETF (Internet Engineering Task >>>>> Force) standard [3]. >>>>> The Link Set format is described at [4]. It is proposed this approach is >>>>> used to generate JSON for a MapServer "homepage". >>>>> The generated JSON format can be seen at >>>>> https://demo.pygeoapi.io/api-catalog.json, with an extract below: >>>>> >>>>> { >>>>> "linkset": [ >>>>> { >>>>> "anchor": "https://demo.pygeoapi.io/master";, >>>>> "service-desc": [ >>>>> { >>>>> "href": "https://demo.pygeoapi.io/master/openapi?f=json";, >>>>> "title": "pygeoapi - latest GitHub 'master' version (JSON)", >>>>> "type": "application/vnd.oai.openapi+json" >>>>> } >>>>> ], >>>>> "service-doc": [ >>>>> { >>>>> "href": "https://demo.pygeoapi.io/master/openapi?f=html";, >>>>> "title": "pygeoapi - latest GitHub 'master' version (HTML)", >>>>> "type": "text/html" >>>>> } >>>>> ] >>>>> }, >>>>> >>>>> The spec allows for an additional "service-meta" property "used to link >>>>> to additional metadata about the API, >>>>> and is primarily intended for machine consumption." I think this can be >>>>> used to add any additional properties from Mapfiles >>>>> we'd need to generate a MapServer homepage. >>>>> "service-doc" isn't mandatory, so WxS service links can ignore this. An >>>>> example of the proposed JSON and metadata is shown below: >>>>> >>>>> { >>>>> "linkset": [ >>>>> { >>>>> "anchor": "https://demo.mapserver.org/";, >>>>> "service-desc": [ >>>>> { >>>>> "href": >>>>> "https://demo.mapserver.org/cgi-bin/msautotest?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities";, >>>>> >>>>> "title": "World WMS service", >>>>> "type": "text/xml" >>>>> } >>>>> ], >>>>> "service-meta": { >>>>> { >>>>> "type": "wms", >>>>> "title": "WMS demo server for MapServer, used in the >>>>> msautotest suite", >>>>> "keywords": ["layers", "list"], >>>>> "mapfile": "msautotest.map", >>>>> } >>>>> } >>>>> }, >>>>> >>>>> Seth >>>>> >>>>> [1] https://demo.pygeoapi.io/ >>>>> [2] https://github.com/geopython/demo.pygeoapi.io/pull/60/files >>>>> [3] https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog/08/ >>>>> [4] https://www.rfc-editor.org/rfc/rfc9264.html >>>>> >>>>> >>>>> -- >>>>> web:https://geographika.net & https://mapserverstudio.net >>>>> mastodon: @geographika@mastodon.social >>>>> >>>>> On Sun, Jan 19, 2025, at 5:10 PM, Tom Kralidis wrote: >>>>>> Seth: thanks for this RFC. IETF has api-catalog (draft, [1]) which I >>>>>> think would be a good candidate for this RFC. This is also an item for >>>>>> review in the OGC API - Records SWG [2]. >>>>>> >>>>>> Overall it looks pretty close to the RFC proposal. We can consider >>>>>> using api-catalog as a baseline and we can extend the JSON accordingly >>>>>> as needed for anything specific to our needs. >>>>>> >>>>>> Cheers >>>>>> >>>>>> ..Tom >>>>>> >>>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog >>>>>> [2] https://github.com/opengeospatial/ogcapi-records/issues/355 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jan 18, 2025 at 5:39 PM Seth G via MapServer-dev >>>>>> <mapserver-dev@lists.osgeo.org> wrote: >>>>>>> Looking again at the landing page JSON at >>>>>>> https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi?f=json it >>>>>>> is in the same format, so as you suggested could simply be expanded >>>>>>> with links to WxS services, or even CGI generated responses. This would >>>>>>> also more easily allow template reuse. >>>>>>> >>>>>>> Seth >>>>>>> >>>>>>> -- >>>>>>> web:https://geographika.net & https://mapserverstudio.net >>>>>>> mastodon: @geographika@mastodon.social >>>>>>> >>>>>>> On Sat, Jan 18, 2025, at 11:33 PM, Seth G via MapServer-dev wrote: >>>>>>> > Hi Even, >>>>>>> > >>>>>>> > Thanks for your valuable feedback. >>>>>>> > >>>>>>> > The homepage would be a "superset" of all available Mapfiles in a >>>>>>> > MapServer deployment, as listed in the CONFIG file. Each individual >>>>>>> > Mapfile would still have its own OGC API landing page, so the homepage >>>>>>> > is best described as a directory of all landing pages. >>>>>>> > >>>>>>> > As most MapServer deployments will likely be serving out a combination >>>>>>> > of WxS and new OGC API services for some time to come, it will allow >>>>>>> > both types to be listed together (I'm unaware of a OGC API spec that >>>>>>> > would cover this). >>>>>>> > >>>>>>> > In regard to the JSON used for links, I was modelling it as closely as >>>>>>> > possible to OGC API conventions. Looking at the pygeoapi demo home >>>>>>> > page, it provides a set of links in a common format, so I'll likely >>>>>>> > switch to this format/approach: >>>>>>> > >>>>>>> > https://demo.pygeoapi.io/stable?f=json >>>>>>> > >>>>>>> > A few of the "rel" values are defined as below, and can be reused: >>>>>>> > >>>>>>> > alternate Provides an alternate representation (e.g., HTML >>>>>>> > version of a >>>>>>> > resource). >>>>>>> > service-desc Links to the machine-readable API description (e.g., >>>>>>> > OpenAPI JSON). >>>>>>> > service-doc Links to the human-readable API documentation (e.g., >>>>>>> > OpenAPI HTML). >>>>>>> > conformance Lists the standards and conformance classes supported by >>>>>>> > the API. >>>>>>> > >>>>>>> > I'll update the RFC with the above, >>>>>>> > >>>>>>> > Seth >>>>>>> > >>>>>>> > -- >>>>>>> > web:https://geographika.net & https://mapserverstudio.net >>>>>>> > mastodon: @geographika@mastodon.social >>>>>>> > >>>>>>> > On Sat, Jan 18, 2025, at 12:39 PM, Even Rouault wrote: >>>>>>> >> Seth, >>>>>>> >> >>>>>>> >> Thanks for putting this together. I'm wondering how much your >>>>>>> >> proposal >>>>>>> >> relates/intersects with the concept of the landing page of OGC API >>>>>>> >> services ? You mention some connection with it, but it is not >>>>>>> >> immediately clear to me the exact nature of the connection. Perhaps >>>>>>> >> it >>>>>>> >> is just a matter of clarifying. I have put zero thoughts in it, but >>>>>>> >> it >>>>>>> >> would feel weird to invent a MapServer specific thing, so I'm naively >>>>>>> >> wondering if we can't we just adopt the landing page formalism (for >>>>>>> >> the >>>>>>> >> JSON part), and potentially extend it by exposing old WxS services as >>>>>>> >> well in the links as you suggest? I'm also wondering if there's some >>>>>>> >> best practice used by other projects on how to expose for things like >>>>>>> >> >>>>>>> >> { >>>>>>> >> "href": >>>>>>> >> "https://demo.mapserver.org/cgi-bin/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities";, >>>>>>> >> "title": "GetCapabilities", >>>>>>> >> "type": "WMS" >>>>>>> >> }, >>>>>>> >> >>>>>>> >> so they can be interoperably consumed. >>>>>>> >> >>>>>>> >> Even >>>>>>> >> >>>>>>> >> Le 18/01/2025 à 09:11, Seth G via MapServer-dev a écrit : >>>>>>> >>> Hi devs, >>>>>>> >>> >>>>>>> >>> I've drafted an RFC with an approach of creating a MapServer >>>>>>> >>> homepage based on the MAPs referenced in a mapserver.conf file. >>>>>>> >>> This will allow MapServer installations to easily advertise >>>>>>> >>> available services, dynamically. >>>>>>> >>> >>>>>>> >>> Text available in pull request at >>>>>>> >>> https://github.com/MapServer/MapServer-documentation/pull/996 >>>>>>> >>> >>>>>>> >>> Comments and thoughts appreciated, >>>>>>> >>> Thanks, >>>>>>> >>> >>>>>>> >>> Seth >>>>>>> >>> >>>>>>> >>> -- >>>>>>> >>> web:https://geographika.net & https://mapserverstudio.net >>>>>>> >>> mastodon: @geographika@mastodon.social >>>>>>> >>> _______________________________________________ >>>>>>> >>> MapServer-dev mailing list >>>>>>> >>> MapServer-dev@lists.osgeo.org >>>>>>> >>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >>>>>>> >> >>>>>>> >> -- >>>>>>> >> http://www.spatialys.com >>>>>>> >> My software is free, but my time generally not. >>>>>>> >> Butcher of all kinds of standards, open or closed formats. At the >>>>>>> >> end, >>>>>>> >> this is just about bytes. >>>>>>> > _______________________________________________ >>>>>>> > MapServer-dev mailing list >>>>>>> > MapServer-dev@lists.osgeo.org >>>>>>> > https://lists.osgeo.org/mailman/listinfo/mapserver-dev >>>>>>> _______________________________________________ >>>>>>> MapServer-dev mailing list >>>>>>> MapServer-dev@lists.osgeo.org >>>>>>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >>>>> >>> >>> >>> _______________________________________________ >>> MapServer-dev mailing list >>> MapServer-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> >> >> -- >> Daniel Morissette >> Mapgears Inc >> T: +1 418-696-5056 #201 >> _______________________________________________ >> MapServer-dev mailing list >> MapServer-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev >> > > > -- > Richard W. Greenwood > www.greenwoodmap.com > > _______________________________________________ > MapServer-dev mailing list > MapServer-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-dev >
_______________________________________________ MapServer-dev mailing list MapServer-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-dev
